Fast-path answers computed in a coordinator process: probe large request parameters for memory and event-loop blocking

When a review adds a fast path that answers requests in the main or coordinator process (e.g. from a precomputed descriptor) instead of a worker that has an RSS cap, byte-exactness tests aren't enough. Send the protocol's maximum parameters (here buckets = MAX_BUCKETS = 2^22 over spans of millions of changes). At the same time, send a cheap request (e.g. stats) alongside and time it, and sample the coordinator's VmRSS from /proc/<pid>/status every 20 ms. In one case the answers were byte-identical to the worker's, but the coordinator blocked for 4-9 s and grew from 300 MB to 1.8 GB, while the worker path stayed at about 330 MB. The fix is a size gate: take the fast path only under a bucket/count bound and leave the rest to the worker.

Also, when reproducing a small A/B overhead claim (+1-3%), note the host load. The same ABBA benchmark gave +9% p50 / +27% p95 on a host at load 9 on 12 cores, because the background job competes for CPU. Claims like this need their conditions (idle host, one worker, features off) stated next to the numbers.