Fix(finmail): resolve unbounded sender_name storage with length guard

[Jean-Regis-M]

Summary

Fixes #348

Rejects sender_name values exceeding 100 characters in send_email before
they reach the database, preventing oversized strings from poisoning LLM context
on every list_inbox call.

---

Problem

send_email accepted arbitrarily long sender_name values with no length
validation. A caller could pass a 10,000-character string which was:

1. Stored verbatim in the emails table via route_and_deliver
2. Returned in every list_inbox summary response via to_summary_dict()
3. Injected into LLM context on every inbox listing — not just on direct read calls

Reproduction:

send_email(sender_name='A' * 10_000, to=["admin@ns.finbot"], subject="x", body="y")
# Expected: {"error": "sender_name exceeds maximum length of 100 characters"}
# Actual:   stored verbatim, no error returned

---

Root Cause

effective_sender was forwarded directly to route_and_deliver without any
length check:

effective_sender = sender_name or config.get("default_sender", "OWASP FinBot")
# ← no validation here
return route_and_deliver(..., sender_name=effective_sender, ...)

This allowed unbounded strings to persist in the DB and surface in all
subsequent inbox listing responses.

---

Solution

Added a module-level constant and an early-return guard immediately after
effective_sender is resolved — before any DB interaction occurs:

MAX_SENDER_NAME = 100

effective_sender = sender_name or config.get("default_sender", "OWASP FinBot")
if len(effective_sender) > MAX_SENDER_NAME:
    return {"error": f"sender_name exceeds maximum length of {MAX_SENDER_NAME} characters"}

No other code paths, function signatures, or DB schema are affected.

---

Files Changed

File	Change
finbot/mcp/servers/finmail/server.py	Added MAX_SENDER_NAME = 100 constant + 2-line length guard in send_email

---

Edge Cases Covered

Input	Behavior
sender_name="" or omitted	Falls back to default_sender ("OWASP FinBot") passes ✅
sender_name="A" * 100	Exactly at limit passes ✅
sender_name="A" * 101	Rejected with error dict ✅
sender_name="A" * 10_000	Rejected immediately, never reaches DB ✅
Unicode characters	len() counts code points safe for a name field ✅

---

Impact

• No breaking changes all names ≤ 100 chars pass unchanged
• Minimal diff 1 constant + 2 lines of guard
• Consistent with existing error-return pattern used throughout the file
• Zero changes to route_and_deliver, DB schema, or any other tool
• Deterministic and side-effect free

---

Testing

# Validates the fix
pytest tests/unit/mcp/test_finmail.py::TestEmailAddressValidation::test_fm_addr_005_very_long_sender_name_accepted_without_validation -v

# Regression — must continue to pass
pytest tests/unit/mcp/test_finmail.py::test_fm_send_001_send_email_to_vendor_inbox -v

Before fix:

result = send_email(sender_name='A' * 10_000, ...)
assert "error" not in result  # passed (bug)

After fix:

result = send_email(sender_name='A' * 10_000, ...)
assert result == {"error": "sender_name exceeds maximum length of 100 characters"}  # passes ✅

---

Checklist

• Directly fixes the reported root cause
• No unrelated code touched
• No refactoring introduced
• Matches existing error-return conventions
• Both acceptance criteria from issue Bug_139_MUST_FIX: MCP-FM-ADDR-005 — 10,000-character sender_name accepted; poisons LLM context on every inbox listing #348 satisfied