[FEA] Evaluate fusing AST evaluation into the HashCSR retrieve kernel

**Is your feature request related to a problem? Please describe.**

Mixed joins previously ran fused AST and join kernels that suffered low occupancy from register pressure. Three components were monomorphized and fully inlined into one kernel body, keeping many values live at once: cuco's probing kernels, the row operators, and the AST evaluator.

#23012 split that into `hash_join` followed by `filter_join_indices` (#20385), so no single kernel carries all three. The join kernel keeps cuco and the row operators, the filter kernel carries only the AST evaluator. The cost is that the join now materializes the full unfiltered index pair before filtering it.

**Describe the solution you'd like**

#23640 replaces cuco's templated kernels with a hand-rolled table and four purpose-built kernels, removing one source from the join side. A re-fused kernel would therefore carry the row operators and the AST evaluator, but not cuco. Evaluate whether that pair fits in a register budget that still gives acceptable occupancy.

The win is not fewer passes; HashCSR is count, scan, fill, probe-count, scan, retrieve either way. It is that a fused retrieve never materializes the unfiltered indices, which should matter most when the predicate is selective and the pre-filter match count is large.

Measure before committing: registers per thread and achieved occupancy for the fused retrieve kernel, peak memory, and end-to-end mixed join time against the current two-stage path, swept over predicate selectivity and match count.

**Describe alternatives you've considered**

Keep the two-stage path from #23012. It already resolved the occupancy problem, and its only cost is the intermediate allocation, which is negligible for unselective predicates.

**Additional context**

Given #23532, the row operators alone may dominate the budget, in which case fusing regresses occupancy regardless of cuco's removal and the current split stays.

Start by tracing the current two-stage path from hash_join through filter_join_indices and the HashCSR count, scan, fill, probe-count, scan, and retrieve stages. Compare it with the purpose-built kernels from #23640 and the occupancy concerns in #23532. Done means measured registers per thread, achieved occupancy, peak memory, and end-to-end mixed-join time across predicate selectivity and match count, with a decision on whether fusion is worthwhile.

Written by the indexing model from the issue text.