fix(streaming): add delta_only mode so pure-delta chunks are never dropped (fixes #9)

[Xuxchloris]

Fixes #9

Problem

merge_streaming_text (used by MarkdownStreamController.append) corrupts streamed text from pure incremental-delta producers: whenever a new chunk's leading character equals the trailing character of the accumulated content, that character is silently dropped. 404 renders as 40, 2100138470 as 210138470, 2026-07-23 as 2026-07-2.

Root cause: the merge heuristics (rewind detection prev.startswith(chunk) and longest suffix/prefix overlap) are correct for accumulated/mixed producers but wrong for pure-delta producers — for those, every chunk is brand-new text, so a chunk like 4 after 40 (or 0 after 210) must be concatenated, never treated as a rewind or overlap. The two semantics are indistinguishable from the (prev, chunk) pair alone, so the correct fix is to make the merge strategy explicit.

Changes

• lark_channel/channel/outbound/streaming/merge_text.py: merge_streaming_text(prev, chunk, *, delta_only=False) — delta_only=True performs a plain concatenation (empty-input guards only), so pure-delta producers never lose characters. The default keeps the existing heuristics and behaviour unchanged.
• lark_channel/channel/outbound/streaming/markdown_stream.py: MarkdownStreamController gains an optional delta_only: bool = False constructor flag, forwarded to the merge in append().
• lark_channel/channel/tests/test_streaming_primitives.py: new tests — delta-only merge for the exact issue cases (40+4→404, 210+0→2100, 2026-07-2+3→2026-07-23), default-mode behaviour unchanged, and a controller-level test asserting the final card content keeps every character.

Verification

• python -m pytest lark_channel — 992 passed; the single failure (test_upload_error_propagation.py::test_gather_buffer_missing_local_file_raises_upload_failed) is a pre-existing Windows-only path-escaping assertion unrelated to this change (CI runs on Linux).