fix(email): add splits_long_messages = True to prevent hard-truncation at 4000 chars (#61990)

[webtecnica]

Summary

Email delivery was hard-truncating outgoing messages at ~4000 characters because EmailAdapter did not declare splits_long_messages = True. SMTP has no practical per-message limit at that scale — the adapter itself defines MAX_MESSAGE_LENGTH = 50_000.

Root Cause

gateway/delivery.py checks adapter.splits_long_messages: when False (default), content is hard-truncated to 4000 chars with a [... truncated] footer. All chat adapters (Telegram, Discord, Slack, etc.) set this to True; EmailAdapter was missing it.

Change

Added splits_long_messages = True as a class attribute on EmailAdapter.

Verification

Lint passes clean. No test suite exists for email adapter yet.

[alt-glitch]

This was generated by AI during triage.

Duplicate of #62000 — both add the identical one-line splits_long_messages = True class attribute to EmailAdapter (verified byte-for-byte). #62000 was opened ~80 min earlier and additionally includes a regression test, so it is the canonical fix. Related: #53264 (broader long-body-splitting variant for the same issue #61990) and issue #61990 (the spec).

[teknium1]

Thanks for isolating the missing capability declaration.

Problems

• This PR does not add a regression test for the affected delivery path. gateway/delivery.py:416-451 makes the truncation decision from adapter.splits_long_messages; the existing generic coverage only verifies a synthetic chunking adapter in tests/gateway/test_delivery.py:335-346, not EmailAdapter.

Suggested changes

• Add a focused router-to-email test that delivers content over 4,000 characters and asserts the mocked EmailAdapter.send() receives the complete payload without the truncation footer.

Automated hermes-sweeper review.

[webtecnica]

Closing as duplicate — the sweeper identified this as already covered by another PR. Thanks for the contribution!