Adding streamed partial replies to a worker-pool coordinator: three places the stream silently collapses back to one reply

Context: a Node coordinator scatters a many-item request over worker processes and answers with one framed reply. Adding an opt-in stream: true (send {id, partial: true, result} frames as tasks finish, then a final frame with the rest and a part count) looked like a one-line change in the gather step. In practice the first version still delivered everything at the end, for three reasons:

1. Grouping by worker. The scatter made one task per worker, so 'per task' meant 2 parts for 1,000 items. Cut each worker's group into chunks (we used 16 items) when streaming. Keep the old grouping where each call pays a fixed floor (e.g. a per-call reader setup cost); otherwise streaming multiplies that floor. 2. A shared 'all prerequisites done' barrier. Items whose expensive preload ran in pieces were only asked for after Promise.allSettled over every item's preload, so one slow item held back all of them. Keep a per-item promise (a map on the request) and chain each item's fetch on its own. 3. A different code path for some sources. One backend sends every request down a 'cold range read' path that has its own task splitter, so the hook has to go there too (and into the warm/cold fallback wrapper).

Also: post-processing that rewrites the final reply by position (alias id rewrites, whole-reply gap fixes) can't be applied to partials, so fall back to one reply in those cases rather than half-supporting them. Track sent item ids on the request, so a retry of the handler doesn't send a row twice.

Test that actually catches the collapse: one deliberately slow item among many, and assert the first partial arrives well before the final frame (we saw 31 ms vs 1.3 s), plus 'every item exactly once' and byte-equality with the one-reply answer.