Benchmark bool run-end decode over fixed corpora

[joseph-isaacs]

Rationale for this change

run_end_decode's bool cases give every run the same length and derive its value from the run index, then decode that one array over and over. Both properties flatter a decoder:

• the run length is a loop-invariant constant, so per-run setup that would cost something on irregular data is hoisted or predicted away;
• the per-run branch on the run's value — the branch an adaptive decode strategy turns on — is perfectly learnable after one pass over a single fixed array.

What those numbers partly measure is the branch predictor's memory of one array, not the decoder. Real bool columns are neither uniform in run length nor repeated.

This lands the measurement first, on its own, so a following change to the decode kernel shows up in CI as a delta against a benchmark that was already there.

What changes are included in this PR?

A new bench target, run_end_decode_bool_corpus:

• decode a set of arrays per sample, not one array repeatedly. Each array is independently generated from its own seed, so no run boundary or run value sequence repeats within a sample and the predictor has nothing to memorise.
• run lengths drawn from a normal distribution about the target average, with a standard deviation of a third of the mean. The spread of run lengths, not the mean, is what sets how often a run crosses a machine word boundary, so the shape matters to what is being measured. Three sigma puts the clamp at one element far enough out that the truncated tail is negligible and the realised mean stays close to the nominal one.
• fixed seeds, so the corpus is byte-identical on every run and in CI.
• working sets (2M and 400k elements per sample) too large to sit in L1.
• decoded arrays are collected and returned, so divan drops them after the timer stops. Dropping each array as it is produced would put a deallocation per array inside the measurement, and decode strategies differ in how many buffers they allocate and at what sizes, so that term moves with the thing being measured rather than being a constant.

Two shapes bracket what a scan sees:

shape	arrays	elements each	per sample
128x16k	128	16,384	2M
4x100k	4	100,000	400k

crossed with average run lengths of 4, 16 and 64 — shorter than a machine word, around a word, longer than a word — and three value mixes: 50/50 values, 90/10 values, and 50/50 values over 90% validity. 18 cases, reported with an ItemsCount counter.

Local walltime for the whole target is a few seconds; the largest single case is ~6.7 ms per sample.

Existing bench targets are untouched, so their CI baselines are unaffected.

One known limitation

Adjacent runs may carry the same value. For a canonically encoded bool column that would be wrong — equal neighbours would merge, forcing strict alternation — but bool run-end arrays are not produced that way. They arise as the validity of an integer run-end array, reusing its ends, or as a comparison pushed into one. Neither merges on bool equality, so non-alternating and skewed values are the realistic shape and the 90/10 cases are meaningful.

Checks run: cargo build -p vortex-runend --benches, cargo bench -p vortex-runend --bench run_end_decode_bool_corpus, cargo clippy -p vortex-runend --all-targets --all-features, cargo +nightly fmt --all, git diff --check.

What APIs are changed? Are there any user-facing changes?

None. Benchmarks only, no library code touched. Adds rand_distr to this crate's dev-dependencies; it is already a workspace dependency used by vortex-array's benches.