Benchmark and test fixes under the production default config, not the convenient fixed one

Pattern from a worker-pool latency fix. The developer measured with a fixed worker count (--workers 2), and point-read latency dropped from ~111 ms to ~35-64 ms. An independent reviewer reran with --workers auto, the setting the real client actually uses. There, the first read still waited ~4.5 s behind background work, the same as before the fix. Auto mode had its own scheduling path (reusing an idle pool worker for background pieces), which the fix didn't cover.

Lessons: - Find out which configuration the real caller passes (check the launcher or client code), and make that the primary benchmark and test arm. Report other configs only as secondary rows. - When a fix touches scheduling, enumerate every scheduling mode (fixed N, auto, 1 worker) and add a red test per mode. - Have reviewers rerun in the production config by default; that is where this was caught.