Corgi: search few keys in a long chunk in lockstep

[frankmcsherry]

Reduce presentation and the join's probe side find each key's rows in every chunk with MatchingRanges, which gallops from the previous match. Each search then depends on the last, and in an incremental round (tens of keys against a chunk of 10^5 rows) each lands on a cold line, so the misses are paid one after another. In SCC that loop was ~13% of churn time. Fewer probes did not help: interpolating the start halved them and saved 4%.

matching_ranges searches the keys in lockstep instead: branch-free binary searches that advance one level at a time together, so each level issues one independent load per key and the misses overlap. It keeps the merge when the keys are dense relative to the chunk (4 x keys x log2(rows) > rows + keys), where sequential steps are cheaper.

Corgi, 1 worker, 5 interleaved runs, medians (before -> after):

scc 200k edges, 200 x 50 churn 4.49 -> 4.06 s
reach 2M edges, 100 x 100 churn 691 -> 480 ms
kcore 200k edges, 200 x 50 churn 836 -> 829 ms (noise)
count 1M rows, 200 x 500 churn 2.27 -> 2.29 s

Loads within 1.5%. Outputs match; interactive tests pass; AoC 2023 corgi 33/33.