Fixes #251

Problem

readLines() in js/src/utils.ts accumulates the response body with buffer += chunk and re-scans the whole buffer on every chunk. String append plus full re-scan is O(n^2): a large single-line stdout (the exact shape produced by print("x" * 22_000_000)) causes multi-second event-loop stalls and OOM kills on memory-constrained hosts, as reported in #251 (Linear: #251).

There is a second, related bug: a fresh new TextDecoder() is created for every chunk, so a multi-byte UTF-8 sequence split across a chunk boundary (any emoji, most non-Latin scripts) decodes as U+FFFD replacement characters.

Fix

• Accumulate decoded fragments in an array (pending). Appending is O(1), and join('') runs only when a line completes, so total work is linear.
• Scan for newlines only within the newly decoded chunk instead of the whole buffer.
• Reuse a single TextDecoder with { stream: true } and flush it at stream end. This fixes the split-sequence decoding and preserves trailing bytes.

Semantics are unchanged: the same lines are yielded for embedded, trailing, and consecutive newlines, and for the final unterminated remainder.

Benchmark

Node v24, 64 KiB chunks, single-line payload terminated by \n (the #251 scenario):

The old implementation scales roughly 4x per size doubling (quadratic); the new one scales linearly and is 77x faster at 88 MB.

Tests

Added js/tests/utils.test.ts with 9 unit tests covering line splitting across chunk boundaries, empty lines, trailing text without a newline, empty streams, multi-byte UTF-8 split across chunks, incomplete sequences at stream end, and a ~8 MB many-chunk case. These are pure unit tests over a synthetic ReadableStream, so no sandbox or API key is needed. pnpm test tests/utils.test.ts, pnpm build, and pnpm lint all pass.