fix: prevent silent content loss when splitting long messages

[kevin-david]

Why

splitMessageImpl was discarding the tail of any single paragraph longer than maxLength via para.slice(0, maxLength) — that tail vanished. Visible symptom: long fenced blocks (ASCII tables, etc.) ended mid-row with the rest of the response missing entirely. Caught by instrumenting the finalize path and noticing chunk sizes summing to less than the buffer length on every split (e.g. buffer=2706, chunks=[63,1904], 739 chars lost).

What changes

Rewrite splitMessageImpl to never drop content:

• Paragraph fits in current chunk → append normally
• Paragraph alone too long → flush current, split the paragraph by lines
• Single line too long → hard-split by characters (last-resort fallback)

Add balanceCodeFences post-pass: when a chunk ends with an open ``` fence, close it there and re-open with the same language tag at the start of the next chunk. Without this, a fenced block split across multiple Discord messages renders as one fenced + one raw-text message.

Test plan

• Verified by tailing [MessageDraft.finalize] splitting debug logs — chunk sizes now sum to (slightly more than) the buffer length, with overflow accounted for by fence re-balancing
• Reviewer: send a /new session prompt that elicits a long fenced response (~3000+ chars). Confirm all content arrives across multiple Discord messages with intact fences.
• Verify works in Claude (mostly testing with Gemini)

[0xmrpeter]

Solid and necessary fix — the content loss bug is real and well-diagnosed. The regression test is especially well done; documenting the original failure shape with the comment explaining the old truncation path is exactly the right approach.

One edge case worth addressing before merge:

balanceCodeFences can misidentify a closing fence as an opening one — when pushLines isolates a standalone ``` into its own chunk (e.g., after flushing the content lines before it), the fence count comes out odd and pendingOpenFence gets set. The continuation chunk then gets an untagged ``` block prepended instead of the correct language tag (e.g., ```python). A test that splits inside a named-language fence where the closing ``` ends up isolated would cover this — verify that the correct language tag propagates all the way through, not just an empty one.

Also a pre-existing note: splitMessage is marked @deprecated but is the live code path in streaming.ts:163 — worth tracking separately to avoid confusion.

Great work overall!

[kevin-david]

Solid and necessary fix — the content loss bug is real and well-diagnosed. The regression test is especially well done; documenting the original failure shape with the comment explaining the old truncation path is exactly the right approach.

One edge case worth addressing before merge:

balanceCodeFences can misidentify a closing fence as an opening one — when pushLines isolates a standalone ``` into its own chunk (e.g., after flushing the content lines before it), the fence count comes out odd and pendingOpenFence gets set. The continuation chunk then gets an untagged ``` block prepended instead of the correct language tag (e.g., ```python). A test that splits inside a named-language fence where the closing ``` ends up isolated would cover this — verify that the correct language tag propagates all the way through, not just an empty one.

Also a pre-existing note: splitMessage is marked @deprecated but is the live code path in streaming.ts:163 — worth tracking separately to avoid confusion.

Great work overall!

Thanks for the review @0xmrpeter - updated now with another bug fix I found while manually testing. TDD with AI is a lot of fun!