fix(telegram): fix 4 streaming truncation bugs — safe_limit, cursor cleanup, metadata forwarding, overflow chunking

[ZK-Snarky]

Summary

Four bugs that cause messages to be cut off, garbled, or land in the wrong Telegram topic during streaming. All four affect anyone using supergroup forum topics, which is a growing use case since group_topics skill binding merged.

---

Bug 1: MDv2 escape inflation blows past 4096 (stream_consumer.py)

The old safe_limit was _raw_limit - len(cursor) - 100 at roughly 3994 chars. MDv2 escaping adds a backslash before every special character (. - ( ) _ etc.), inflating formatted length 10-20% above raw. A 3994-char raw chunk becomes 4200+ after format_message(), triggering a Telegram 400 on the edit.

Fix: _safe_limit = max(500, int(_raw_limit * 0.75)) at 3072 chars, leaving real headroom for escape inflation.

---

Bug 2: Cursor stuck in split messages (stream_consumer.py)

When an overflow split fires, the first chunk cursor-removal edit can fail and set _edit_supported = False. All subsequent edits including the final cursor-removal on the second chunk are then silently skipped. Both messages keep the cursor artifact permanently.

Fix: bypass _edit_supported for cursor-removal operations. Call adapter.edit_message() directly with a single retry instead of routing through _send_or_edit().

---

Bug 3: metadata not forwarded in edit path (stream_consumer.py)

_send_or_edit called adapter.edit_message() without metadata=self.metadata, so thread_id was unavailable. Overflow chunks landed in the main chat instead of the correct supergroup topic.

Fix: pass metadata=self.metadata at all edit_message call sites in stream_consumer.

---

Bug 4: edit_message overflow truncates instead of chunking (telegram.py)

The message_too_long handler in edit_message() cut content to 4076 chars plus ... and dropped the rest silently. This loses content on any long streaming response.

Fix: split content into 80%-limit chunks via truncate_message(). Edit the first chunk in place, then send remaining chunks as new messages with message_thread_id=effective_thread_id to keep them in the correct topic. The edit_message signature gains an optional metadata param to make thread_id available.

---

Bonus: normalize \r\n line endings in format_message() (telegram.py)

API responses from Close.com, GHL, and other external systems frequently use Windows (\r\n) or old Mac (\r) line endings. Telegram renders \r as a visible character, producing garbled output.

Fix: one-liner normalize at the top of format_message().

---

Testing

All four bugs were reproduced and fixed in a live Falcon HQ supergroup with forum topics enabled. The safe_limit change is conservative at 3072 chars, which gives consistent clean splits without MDv2 inflate errors.

[trevorgordon981]

Four genuinely distinct bugs, each with a clear repro and a targeted fix. Bug 1 (MDv2 escape inflation blowing past 4096) is a great catch — byte-count vs. rendered-length divergence is exactly the thing that slips through. The 0.75 × raw_limit safety factor is conservative-correct. Bug 2 (cursor stuck after first edit sets _edit_supported=False) is a nasty state-leak. Only live testing called out — would be worth a unit test asserting a 3800-char payload with heavy MDv2-escape chars gets split before the 4096 ceiling, to lock in the safe_limit regression. Proceed.

[ZK-Snarky]

Closing — the upstream refactor of gateway/stream_consumer.py (the new _send_or_edit abstraction) absorbed bugs #2 (cursor in split messages) and #4 (overflow chunking). The remaining bugs (#1 safe_limit MDv2 inflation, #3 metadata forwarding in edit path) no longer warrant a 134-line PR on their own. Thanks to @trevorgordon981 for the original review.