What Problem This Solves

chunkByNewline (src/auto-reply/chunk.ts) length-splits a single over-long line that has no usable break point. The first head cut used a raw UTF-16 slice — lineValue.slice(0, firstLimit) — so when firstLimit landed inside a surrogate pair, it emitted a chunk ending in a lone high surrogate and a next chunk starting with a lone low surrogate. Those unpaired surrogates render as U+FFFD (�) when the message is delivered. The recursive chunkText that handles the remainder is already surrogate-safe (it routes cuts through avoidTrailingHighSurrogateBreak); only this first head cut was raw.

Why This Change Was Made

Surrogate-splitting is treated as a defect across this codebase — avoidTrailingHighSurrogateBreak exists for exactly this, chunkText/chunkMarkdownText already use it, and chunk.test.ts asserts chunks must never end in a high surrogate or start with a low surrogate. The head cut in chunkByNewline was the one path that skipped it. The fix routes that cut through the same helper, backing it off to a code-point boundary. ASCII and any non-surrogate cut are unaffected (the helper is a no-op there).

User Impact

chunkByNewline is the published plugin-SDK channel helper (runtime.channel.text.chunkByNewline), used to chunk outbound channel messages. Emoji-dense lines that exceed the per-line limit no longer get a mojibake � at the split boundary. No API or config change.

Evidence

oxfmt, oxlint, tsgo:core all pass; the full chunk.test.ts suite passes with a new regression test, and reverting the one-line fix makes that test fail (fail-before).

Real behavior proof

Behavior addressed: chunkByNewline split a surrogate pair on the first hard cut of an over-long line, emitting a chunk ending in a lone high surrogate and the next starting with a lone low surrogate (renders as U+FFFD on delivery).

Real environment tested: Ran the exported chunkByNewline from src/auto-reply/chunk.ts via tsx on Node v22.22.1 (no mocks), before and after the patch, plus the colocated Vitest suite via node scripts/run-vitest.mjs.

Exact steps or command run after this patch: chunkByNewline("😀".repeat(30), 11) and chunkByNewline("a" + "😀".repeat(5000), 4096) (the production-default 4096 limit), checking each chunk against /[\uD800-\uDBFF]$/ (lone trailing high surrogate) and /^[\uDC00-\uDFFF]/ (lone leading low surrogate); then node scripts/run-vitest.mjs src/auto-reply/chunk.test.ts, node scripts/run-oxlint.mjs, pnpm tsgo:core.

Evidence after fix:

BEFORE (origin/main):
  chunkByNewline("😀"x30, 11)          -> chunk[0] ENDS in lone HIGH surrogate (len 11); chunk[1] STARTS with lone LOW surrogate
  chunkByNewline("a"+"😀"x5000, 4096)  -> chunk[0] ENDS in lone HIGH surrogate (len 4096); chunk[1] STARTS with lone LOW surrogate
AFTER:
  chunkByNewline("😀"x30, 11)          -> 6 chunks, splits-surrogate = false
  chunkByNewline("a"+"😀"x5000, 4096)  -> 3 chunks, splits-surrogate = false; join("") reconstructs the input exactly
  chunkByNewline("a"x50, 20) (control) -> unchanged (no surrogates)
vitest chunk.test.ts -> exit 0 (all pass, incl. new regression test); fail-before (revert source) -> the new test fails
oxlint -> exit 0 ; tsgo:core -> exit 0

Observed result after fix: no chunk ends in a lone high surrogate or starts with a lone low surrogate for emoji-dense over-long lines (at both a tiny limit and the production-default 4096); content is preserved (join("") equals the input); ASCII/non-surrogate splitting is byte-identical to before.

What was not tested: a full live channel send rendering the emoji end-to-end on a specific platform UI (no live channel in this environment); the fix is a pure text-chunking change proven at the function and unit-test level, and the surrogate-integrity contract matches the existing chunkMarkdownText tests.