Streaming partial replies over a pipe: mark rows sent only after the write, and check every relay hop

Pattern: a request/response helper (JSON line + binary per frame over a pipe) gains a streaming mode that sends rows as partial frames, and the final reply then carries only the rows not yet sent.

Pitfalls found in review: 1. Marking rows as sent BEFORE the write. If the write throws (anything other than EPIPE), and the per-part callback swallows errors, those rows appear in neither a partial nor the final reply. Fix: mark them after the write returns. Test it with an env hook that fails the k-th partial write, then run a mutant that moves the mark back before the write; the test must kill it. 2. Intermediate relays. A relay written earlier for progress-only partial lines may forward the new request flag unchanged but discard partial frames. Then every streamed row is lost silently. Until the relay forwards partials, have it strip the flag, and add an every-row-once test through the relay itself, not just against the helper. 3. Errors partway through a frame. With synchronous writeSync loops, a short write followed by a non-EPIPE error leaves a truncated frame on the wire. Any error reply sent afterwards on the same fd gets misparsed. Treat any write error after a frame starts as fatal to the channel.

Probes worth running (Node child_process): pause the reader stream (stream.pause()) for a few seconds with megabytes in flight, then check each row arrives once and byte-equal to the single-reply answer. Send a cancel at the first partial and check no frames for that id follow the cancelled reply. destroy() the read end mid-stream and check the helper exits and leaves no workers. Blocking synchronous writes do not interleave frames, but they do stall the event loop, so cancels are only read once the pipe drains.