perf(compare): hoist e_minmax into a dense array — store −71%, run_dada −20% (#147)

[cjfields]

Closes the first half of #147: b_compare's serial store.

The tell

#143's fold
left the store as the entire remaining serial block, at a flat
18.4–19.6 ns/raw-visit across a 5× range in pool size. A per-unit cost that
does not move when the working set moves five-fold is not a residency problem.
It is a fixed per-access price — a cache miss on every access.

The arithmetic settles what the store is before any run: on soil 16S R1 it
walks 11,888,798,623 raw-visits and commits 12,082,545 of them, 0.102%. So
99.9% of the store is the scan, and the commit path can be ignored.

The measurement

examples/store_bandwidth (first commit) decomposes the scan into its component
streams at the real pool size and store rate. Every read goes through
black_box — the first draft reported 574 GB/s because the single-array arms
auto-vectorised while the paired arms could not.

Reproduced on two machines and under both release and release-native:
the strided Raw read is 83–87% of the scan; the result vector, a clean
sequential stream, is nearly free.

Raw is 160 bytes. e_minmax is an f64. Each read pulled a 64-byte line to
use 8 bytes of it, in an order that defeats the prefetcher.

The change

e_minmax moves off Raw into a Vec<f64> on B, parallel to the
B::raw_cluster array that is already there. Seeded to the same -999.0
sentinel Raw::with_qual used to set, and — like the field it replaces —
deliberately not reset by B::init.

Result

Two replicates per arm, both reads, exclusive node (compute-5-6, EPYC 7713),
64 threads, numactl --interleave=all.

soil 16S	main	this PR	change
store R1	227.2 / 223.7 s	63.8 / 63.6 s	−71.7%
store R2	275.4 / 277.9 s	80.2 / 81.2 s	−70.8%
store ns/raw-visit R1	19.1 / 18.8	5.4 / 5.3	18.9 → 5.4
store ns/raw-visit R2	18.7 / 18.9	5.5 / 5.5	18.8 → 5.5
run_dada R1	834.2 / 820.5 s	654.1 / 667.4 s	−20.1%
run_dada R2	926.4 / 960.5 s	735.4 / 749.1 s	−21.3%

Soil ITS2 returns −69% of store time and −15.2% of run_dada on both reads.

Correctness: all 300 per-sample outputs across the six 16S runs are
byte-identical once the embedded build hash is excluded; 240/240 on ITS2.

Controls: b_shuffle sits at 112.5–115.3 s across every 16S arm and
reconcile at 40.2–41.2 ns/comp. The untouched phases did not move, which is
what rules out a whole-run effect presenting as a phase win.

Occupancy — the observable that prompted this: effective cores
((map thread-busy + serial wall) / run_dada) go 31.4 → 38.4 on R1 and
29.4 → 36.5 on R2, of 64.

A note on the synthetic

store_bandwidth bracketed this at −6 to −17% of run_dada and I recommended
planning against −6%. The real result is −20%: the microbenchmark isolated the
right mechanism while understating its magnitude ~3×. Worth recording, because
it means the synthetic's ranking of levers was trustworthy even though its
arithmetic was not.

Not in this PR

The 16 B result-vector collect (ef46356, on perf/store-scan-147) is held
back. It is real but ambiguous — −5.9% / −1.5% wall on ITS2, sys collapsing
93%, and user rising 6–12% with no established mechanism — and the leading
account (glibc's 32 MB mmap threshold cap) predicts that the allocation,
not the element width, is the thing to fix. Reusing one scratch buffer across
calls would remove it at either width; that gets prototyped and measured next.

Docs: docs/findings/compare-store-scan.md, plus CHANGELOG.