fix: make ndJsonStream receive path linear in message size

[benbrandt]

Fixes #206

Problem

The receive side of ndJsonStream accumulated undelivered bytes in a string and re-split the entire buffer on every incoming chunk:

content += textDecoder.decode(value, { stream: true });
const lines = content.split("\n");
content = lines.pop() || "";

While a large message is still incomplete, each chunk copies and re-scans everything buffered so far, so a message of size M arriving in chunks of size c costs O(M²/c) — blocking the event loop for tens to hundreds of milliseconds on multi-megabyte messages (big tool results, embedded resources, base64 payloads). parseSseStream in the HTTP/SSE transport had the identical pattern (buffer += decode + full-buffer regex split per chunk).

Fix

• New internal LineBuffer class: scans only the newly arrived chunk for 0x0A, keeps incomplete tails as byte segments (copied via slice so a few carried-over bytes don't pin an entire chunk's buffer), and concatenates once per complete line. Receiving an M-byte message costs O(M) regardless of how many chunks it spans.

• ndJsonStream and parseSseStream are both rewritten on top of it, so the stdio and HTTP/SSE receive paths are fixed together and the framing logic is unit-tested in isolation.

• ndJsonStream now skips non-object JSON lines before enqueueing. Previously a valid-JSON primitive line like 42 from a peer threw a TypeError in Connection.receiveMessage and tore down the whole connection; now it's skipped with a warning. Object-shaped messages are passed through unvalidated exactly as before, so lenient peers (e.g. responses carrying error: null alongside result, or requests omitting the jsonrpc field) keep working.

• The connection layer is hardened against the same class of malformed input from any transport: Connection.receiveMessage drops non-object messages instead of throwing on the in operator, and handleResponse fast-rejects a response whose error member is not an object (e.g. error: null, which previously threw while destructuring and closed the whole connection) with RequestError.invalidRequest. The WS/SSE transports' stricter silent-drop validation is tracked separately in Unify JSON-RPC message validation policy across transports #211.

Multi-byte UTF-8 characters split across chunk boundaries remain safe: lines are only decoded once complete, and 0x0A can never appear inside a multi-byte UTF-8 sequence.

The send side is unchanged — holding the writer lock across messages would be an observable behavior change (it would permanently lock output), and the per-message getWriter() churn there is O(1), not quadratic.

Benchmark

Same methodology as the issue (one message fed in 64 KiB chunks, median of 7 runs, Node v24, Apple Silicon):

Message size	ndjson before	ndjson after	sse after
1 MB	3.6 ms	0.9 ms	0.8 ms
5 MB	40.0 ms	3.8 ms	3.6 ms
10 MB	152.1 ms	7.7 ms	6.6 ms

Before grows ~quadratically; after grows linearly on both transports.

Tests

Added: LineBuffer unit tests (chunk boundaries, empty lines, flush), a >100-chunk large-message test and non-object-line and lenient-message pass-through tests for ndJsonStream, and large-event / CRLF-boundary / unterminated-final-event tests for parseSseStream. Full npm run check (lint, format, spellcheck, build, 624 tests, typedoc) passes.

🤖 Generated with Claude Code