Corgi reduce: value ids from a merge of the input runs

[frankmcsherry]

Stacked on #894.

Under primitive keys, present the reduce input by merging each key's runs across the chunks in value order, instead of gathering the matched rows, hashing compound values, and consolidating. Each distinct value is met once with all of its records, which consolidate there, and gets its id there: primitive values keep value-as-id, and others get the next ordinal, which the input pool resolves to the chunk row where the merge met it. Ids ascend with values, so the bridge is built in order, with no hash or map, and no column is gathered unless the reducer asks for values.

Hashed keys, and values that are not products of u64 leaves, keep the content-hash path (present_input). Input ids resolve only through the input pool, and output ids are still derived from output columns, so the two id spaces never meet.

Same-plan harness, 1 worker, median of 3 (before -> after; count2 and min2 have two-field values):

count2    1M rows, 1000 x 500    load 145 -> 85.4 ms   churn 4.81 -> 3.56 ms/round
count2    1M rows, 10000 x 60    load 145 -> 86.9 ms   churn 31.8 -> 21.7
min2      1M rows, 1000 x 500    load 163 -> 96.2 ms   churn 4.40 -> 3.08
min2      1M rows, 10000 x 60    load 162 -> 96.1 ms   churn 31.6 -> 20.0
count     1M rows, 1000 x 500    load 86.2 -> 81.1 ms  churn 3.54 -> 3.42
min       1M rows, 1000 x 500    load 86.5 -> 81.5 ms  churn 2.71 -> 2.60
distinct  1M rows, 1000 x 500    load 84.9 -> 81.6 ms  churn 2.45 -> 2.33
reach     2M edges, 1000 x 100   load 680 -> 675 ms    churn 76.6 -> 75.5
scc       200k edges, 100 x 50   load 667 -> 666 ms    churn 35.3 -> 34.8

Peak RSS for a 4M-row load: count 1145 -> 805 MiB, count2 1397 -> 846 MiB, distinct 1145 -> 804 MiB.

Comment changed: next_window's "equal values share a content-hash id" now reads "equal values share an id".

Validation: outputs match compiled DD on the harness cases at 1 and 4 workers; workspace tests pass.

🤖 Generated with Claude Code