[matt-edmondson]

AsyncProcessStreamReader.ReadToEnd passed each 4096-char read straight to the handler. When a read stopped between the two halves of a surrogate pair, a raw OutputHandler callback got one chunk ending in a lone high surrogate and the next starting with a lone low surrogate. A callback that encodes each chunk on its own then wrote two U+FFFD characters in place of the emoji.

The read loop now lives in an internal static ReadChunks(TextReader, char[], Action<string>). It holds back a trailing high surrogate, puts it in front of the next read, and hands it over on its own if the stream ends without the low half. BOM stripping and the delivery lock work as before, in the callback ReadToEnd passes in.

Tests (AsyncProcessStreamReaderTests, which drive ReadChunks over a StringReader so the chunk boundaries are deterministic):

• the issue's case (4095 chars + 😀 + 5000 chars, 4096-char buffer): no chunk splits the pair, and the concatenated chunks equal the input
• a 1-char buffer delivers each emoji whole
• a lone high surrogate at end of stream is still delivered
• output without surrogates is delivered as read

With the hold-back removed, the first two tests fail. Full suite on Linux/net10.0: 68 passed, 2 skipped (the existing elevation skips). The full multi-target build passes.

Fixes #109

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud