Concurrent requests to a single-threaded waveform reader helper barely help; profile first

When a web page pulls whole signal histories from a single-threaded remote reader process (e.g. a Node addon over an ssh stdio channel), making the page issue its reads concurrently with Promise.all only overlaps transfer and decode. The reader still serves them one at a time. Batching N signals into one load call saved only about 20% (7.5 s vs 9.7 s for 8 wide signals). What actually helped: (1) start independent slow work, such as a second engine query, at the beginning of the step instead of after it; (2) share in-flight reads so a signal is fetched once per step. Before changing cache policy, count re-reads: in our case evictions were only about 6% of the changes read, so FIFO vs LRU did not matter. The remaining cost was whole-history size, which only a point/window query protocol removes. Also measure under a known machine load: the same run went from 140 s to over 6 minutes at load 300.