Compare primitive values through the shared RowFn executor - #10676

## Summary

- Tracking Issue: #9128
- Independent validity candidate: #10742

Routes float32 comparisons through the existing word-packing collectors.
This recovers the measured float32 gains from the RowFn comparison
investigation with two private dispatch changes. It is independent of
the comparison migration and fusion work in #10676 and #10675.

## Changes

Adds `F32` to the existing collector selections for array pairs and
array/constant comparisons. Integer collector policies remain unchanged.
The floating-point documentation now accounts for NaN signs and
payloads.

**Draft pending fresh isolated benchmarks on this head.** Saved
measurements show a consistent float32 gain, but also some unrelated ARM
regressions. The later combined packing/validity candidate had an AVX2
regression that has not been attributed to either change individually.

<details>
<summary>Saved benchmark evidence and validation</summary>

The isolated packing snapshot `4c98df49e379853f8e990d9764791b5330511771`
was compared with frozen `develop` at
`a1693389301e446eec41373cb274d98a303d3ca0`. Measurements used Rust
1.99.1 / LLVM 23.1.1, 16 CGUs, no LTO, CPU 2, and 21 balanced paired
blocks on Graviton3 C7g and Sapphire Rapids C7i. This was native wall
time, not CodSpeed simulation.

Across 48 float32 cases at 8,192 and 65,536 rows, covering array pairs,
both constant orientations, equality/ordering, and four validity shapes,
the median block ratios of equally weighted geometric means were:

| Target | Candidate / baseline time | 95% paired bootstrap interval |
| --- | ---: | ---: |
| NEON | 0.611 | 0.610–0.611 |
| AVX2 | 0.632 | 0.630–0.633 |
| AVX-512 | 0.679 | 0.678–0.681 |

Among all 375 probe cases, the isolated snapshot had no flagged
regressions on AVX2 or AVX-512. ARM had four, including roughly 4.7%
slower u64 multiply and 4.6% slower large f64 equality. Those paths do
not use the changed float32 collector, so their movement is not evidence
of extra float32 work, but it still counts against a no-regression
claim.

A separate combined packing/validity candidate at
`8d8ef8151454bbc73e1cd0b236567542a1401cbe`, based on
`d834a11faa79370b4d2e0bbcc73195f451a8a212`, retained the float32 gain
but regressed large nullable u64 add by about 18% on AVX2. Profiling
found a byte-identical retry hot loop with essentially unchanged
instructions per operation and more cycles. The precise
placement-sensitive mechanism remains unresolved. That combined result
does not isolate this PR.

The combined candidate passed 225 RowFn tests and 232 binary-function
tests on that newer base. Separate native probes checked
scalar-reference results and float/encoding/tail edge cases. The changed
file passed the pinned formatter. These are saved checks, not fresh
validation of this individual PR.

This PR is rebased onto `c750fbd80882f78efd6a2703bc0f3e17f1aca9f9`. The
patch is unchanged by the rebase. Tests and benchmarks were not rerun
after it.

</details>

Signed-off-by: Connor Tsui <[email protected]>

Tracking Issue: #9128

## Summary

Combines planning and execution for eligible RowFn batches in one type
dispatch. This is the shared framework layer for #10676, which contains
the primitive comparison migration. It builds on #10899, which separates
batch inspection from planning and adds the regression cases this PR
must keep passing.

## Changes

- Decodes a direct Boolean batch straight from the borrowed inputs,
after `BatchProbe` has classified all of them, so a later null literal
still skips an earlier fallible expression or device transfer. Fallible
decoders keep valid-row execution.
- Finishes all-null, all-constant, null-free, and dense batches in the
planning visit. Every other batch comes back as a `PartiallyValidBatch`,
the only input that dense retry and valid-row execution accept, so every
caller runs the fast paths first.
- Constructs Boolean output with its validity in the shared executor.
Dense execution masks any output that does not carry that validity, and
a validity of the wrong length returns an error. Primitive-specific CPU
and lane-width packing policies stay out of this layer.
- In builds that enable AVX-512F and AVX-512BW at compile time,
`collect_bool_words_multiversioned` uses the inline packing loop instead
of the `#[target_feature]` copy, so its inlining no longer depends on
codegen-unit placement.

## Performance

This PR lowers the fixed cost of each RowFn call, so CodSpeed shows no
gain for it alone. The gain shows up in #10676, which moves primitive
comparison onto the RowFn executor. To isolate this PR, #11220 applied
the two #10676 commits directly on `develop`. Without this PR,
comparisons on small arrays are 10% to 16% slower than `develop` in CPU
simulation, including the zone map pruning benchmarks, `i64_lt`, and
`timestamp_gte`. The added time barely changes between 16 and 1,024
zones (18.0 µs and 17.3 µs for `int_gt`), so it is paid per call, not
per row. On top of this PR, #10676 shows none of these regressions, and
its walltime comparison gains are larger: `compare_u64_avx2` improves by
31% instead of 16%, and seven more comparison benchmarks improve by 12%
to 18%.

In the AVX-512 build, the RowFn changes moved the deferred Boolean
kernel's AVX-512 packing loop out of its caller's codegen unit, so LLVM
could no longer inline it. CodSpeed reported the two partially valid
`deferred_bool_avx512` cases as 42% and 16% slower. With the last
commit, CodSpeed no longer flags either case. Builds that detect AVX-512
at runtime compile the same code as before. #11220 also shows
`compare_u8_avx512` and `compare_f32_avx512` as 14% and 10% slower
without this PR, which matches the same packing problem, but that
build's assembly wasn't inspected.

CodSpeed on the current head flags three varbin comparison cases and
`random_i8[0.01]` as 12% to 18% slower, and one `take_filter` case as
13% faster. None of them runs a RowFn. #10676 reverses the varbin and
`take_filter` changes without touching their code, so they follow code
placement. `random_i8[0.01]` isn't a stable signal either: its `develop`
baseline moved from 99.6 µs to 119.3 µs between `bc58587` and `c9a3fbe`,
and #11220 moved it 13% the other way.

<details>
<summary>CodSpeed results for #10676 with and without this PR</summary>

The first column is #11220, which compares the #10676 commits on
`develop` with `develop` (`c9a3fbe`). The second column is the #10676
report, which compares the same commits on this PR with this PR
(`b0a64dd`). Against `develop` (`bc58587`), this PR flags none of these
benchmarks. CodSpeed marks the walltime runners as unreliable, and the
two columns come from different runs.

| Benchmark | Mode | Without this PR | With this PR |
| --- | --- | ---: | ---: |
| `int_gt[16]` | CPU simulation | 15.6% slower | not flagged |
| `int_gt[1024]` | CPU simulation | 14.5% slower | not flagged |
| `float_gt[16]` | CPU simulation | 12.2% slower | not flagged |
| `float_gt[1024]` | CPU simulation | 12.1% slower | not flagged |
| `or_chain[16]` | CPU simulation | 12.3% slower | not flagged |
| `or_chain[1024]` | CPU simulation | 11.9% slower | not flagged |
| `is_not_null_pred[16]` | CPU simulation | 11.6% slower | not flagged |
| `is_not_null_pred[1024]` | CPU simulation | 10.5% slower | not flagged
|
| `i64_lt` | CPU simulation | 11.7% slower | not flagged |
| `timestamp_gte` | CPU simulation | 10.3% slower | not flagged |
| `bench_compare_sliced_dict_primitive[(1000, 10000)]` | CPU simulation
| 11.5% slower | not flagged |
| `encode_primitives[f32, (2000, 2)]` | CPU simulation | 12.8% slower |
not flagged |
| `compare_u8_avx512` | Walltime | 14.4% slower | not flagged |
| `compare_u8_neon` | Walltime | 13.3% slower | not flagged |
| `compare_f32_avx512` | Walltime | 10.4% slower | not flagged |
| `compare_float_avx2` | Walltime | 18.4% faster | 28.2% faster |
| `compare_u64_avx2` | Walltime | 15.7% faster | 30.8% faster |
| `lt_i64_nullable_avx2` | Walltime | not flagged | 18.4% faster |
| `compare_int_constant_neon` | Walltime | not flagged | 16.2% faster |
| `compare_int_eq_avx2` | Walltime | not flagged | 15.4% faster |
| `compare_f32_avx2` | Walltime | not flagged | 15.4% faster |
| `compare_int_constant_avx2` | Walltime | not flagged | 15.3% faster |
| `compare_int_avx2` | Walltime | not flagged | 13.5% faster |
| `compare_int_nullable_avx2` | Walltime | not flagged | 12.5% faster |

</details>

<details>
<summary>AVX-512 investigation on EC2</summary>

C7i metal (Xeon Platinum 8488C) with the CodSpeed AVX-512 build flags,
the bench profile, one isolated CPU, and 21 paired blocks of 1,000
samples. Ratios are the median paired ratio to `develop` (`8c87c4c457`).
Below 1 is faster. An A/A comparison of two identical binaries flags
none of the 100 cases.

| `deferred_bool_avx512` case | `develop` | Before fix | With fix |
| --- | ---: | ---: | ---: |
| `ConstantLhs, PartialAccepted` | 32.1 µs | 1.354 | 1.025 |
| `Columns, PartialAccepted` | 37.7 µs | 1.159 | 1.018 |

Before the fix, the kernel executed 15% more instructions per row. LLVM
inline remarks show `collect_bool_words_avx512` inlined on `develop` and
"definition is unavailable" on this branch.

Across all 100 `#[cpu_features]` cases, the fix also returns
`compare_string_lt` to the `develop` speed. It makes two
`intersect_by_rank` cases and one `starts_with` case 3.5% to 5.6%
slower, but those execute the same instructions as before, so the
difference is code placement. The AVX2 build is unchanged.

</details>

<details>
<summary>Historical EC2 framework measurements</summary>

These numbers belong to an older framework replay and do not establish
the performance of this revision. Ratios are the median of 21 paired
candidate/baseline elapsed-time ratios. Below 1 is faster. This compares
the framework alone, F `94be28140d5bd7e6b654af5e462253add2e49044`, with
D `0291778db36809f77ce0219bf9850506d3cba3b6`.

| Workload | C7g NEON | C6a AVX2 | C7i AVX2 build | C7i AVX-512 build |
| --- | ---: | ---: | ---: | ---: |
| `u64` multiply, 8,192 rows | 1.732 | 0.979 | 0.992 | 0.998 |
| Nullable `i64` add, 32,768 rows | 1.006 | 1.004 | 1.154 | 1.005 |

The actual framework pair order was imbalanced: D ran before F in 16
blocks and after it in five. Treat these figures as diagnostic
observations, not reliable causal effect sizes.

EC2 C7g (Neoverse V1), C6a (EPYC 7R13), and C7i (Xeon Platinum 8488C).
Rust 1.99.1 / LLVM 23.1.1, bench profile with 16 CGUs and no LTO,
MiMalloc, CPU 2 pinned. The same 455-case public-path microbenchmark
suite ran serially across hosts, with 21 paired blocks, 10 ms per case,
A/A calibration, and a separate control executable. These are
microbenchmarks, not query results. C7i can dispatch to AVX-512 at
runtime even in its AVX2 build.

</details>

The separately confirmed NEON comparison gains were published in #10843,
which has merged. They do not measure this framework.

CI passed on `b0a64dd`, including all-target, all-feature Clippy with
warnings denied and the Linux, Windows, sanitizer, and Miri test jobs.
The CodSpeed check fails on the flags described above.

---------

Signed-off-by: Connor Tsui <[email protected]>