perf: frame large JSON-RPC messages in linear time

[zhuwenzhuang]

Large app-server history responses can consume a session-load deadline inside the JSON-RPC reader. It appends every stdout chunk to the unfinished line and scans that entire line again, even when no newline has arrived.

Scan only the incoming chunk, retain unfinished fragments, and join once per completed message. Dispose releases retained fragments. The change preserves existing newline framing, malformed-line handling, and decoding behavior; it neither truncates history nor increases timeouts. The separate UTF-8 decoding fix in #397 remains complementary.

Fixes #539.

Validation

• Added four reader tests covering fragmented/coalesced lines, CRLF/blank/malformed lines, already-decoded streams, a complete 64 MiB history response followed by another message, and disposal during an unfinished message.
• npm run typecheck and npm run build pass.
• npm test: 744 passed, 26 skipped, 1 failed. The failure is CodexAcpClient.test.ts > should authenticate with key: an extra warning event appears in the expected method sequence. Running that test with the unchanged main reader reproduces the same failure.
• The self-contained 64 MiB benchmark in Large session loads stall in quadratic JSON-RPC line buffering #539 took 4,269 ms on main and 52 ms after this change (macOS, Node v26.5.0; one measured run per version, payload allocation excluded).
• A downstream test on Linux using an isolated real-session copy reduced the approximately 68.7 MB history-response read from 117.1 s to 1.76 s, retaining all 25 turns and 7,565 items. This measures the history-transport phase, not end-to-end session recovery.