perf(extract, features): use every thread when the batch is small

[RobbinBouwmeester]

Summary

Two stages left most of their threads idle, and the isolation-window-group search (#105) makes that worse rather than better: a group has few windows, and the window was the unit of parallelism. Measured on one band of the 8-12-mer immunopeptidomics run with --threads 24: extract 3.2-3.7 cores busy for the whole stage, features 1.6-2.8.

• extract parallelised across the windows in flight, so windows_in_flight: 4 (set low because the hit accumulator holds those windows, and that is the stage's memory) capped it at four working threads. Each window is now also split across its candidate range. A candidate belongs to exactly one sub-range, so the sub-results are disjoint: they hold the window's hits once between them (no extra memory, which a scan-axis split would have cost), they concatenate instead of merging per candidate, and each candidate's hits still arrive in ascending scan order, so every float reduction downstream is unchanged. The candidate axis is also where the work is, since a peak's cost is dominated by walking its posting list. windows_in_flight becomes a pure memory knob.
• features decoded each chromatogram chunk single-threaded and then computed on it, in series; the decode dominated (3.7 of a 4-minute stage on one band). The loader now runs on its own thread one chunk ahead, so decode and compute overlap, with at most two chunks resident.

Output is unchanged

• CI smoke peptides.tsv / proteins.tsv hashes unchanged; all five stage artifacts byte-identical to the previous binary's on the fixture.
• Real scale, one 16.5M-precursor band of the immunopeptidomics run: psms_extracted, chromatograms and features byte-identical to the old binary's, at 12.8 min against 39.6 min. The two runs had different machine load (the old one shared the host with eleven other extracts), so treat the ratio as indicative, not as a measured speed-up.
• New test candidate_range_split_reproduces_the_unsplit_accumulation: same candidates, same hits, same per-candidate hit order whether a window is probed whole or in three sub-ranges.

Notes

• accumulate_groups spawns its producer into the rayon pool and consumes on the calling thread. The engine calls it from the main thread, which is never a pool worker (build_global), so a one-thread engine is fine; a test that calls it under pool.install with one thread would deadlock, and the test comment says so.
• The two-pass co-elution path (extract_twopass_windows, used by the peak_claim co-elution modes) still parallelises across windows only. Same treatment is possible there and is not in this PR.
• Stacks cleanly with feat(run): search a run one isolation-window group at a time (groups.window_groups) #105: independent files apart from config.rs documentation.

Validation

cargo fmt --check, cargo clippy --workspace --all-targets -- -D warnings, cargo test --workspace (291 tests), ci/smoke.sh with unchanged hashes.

🤖 Generated with Claude Code