Add OnPair LIKE pushdown

[gatesn]

Note: I am putting this up just to stash the code somewhere. In an optimization loop, Claude decided it would implement this... it may be total garbage.
Rational for this change

OnPair can evaluate simple LIKE patterns directly over its tokenized representation instead of canonicalizing the full string array first. This gives OnPair a predicate path for exact, prefix, suffix, contains, and all-match LIKE patterns, and builds on the preceding execution changes that preserve sparse row demand through filters and shared wrappers.

No tracked issue.
What changes are included in this PR?

Adds an OnPair LIKE kernel, wires it into OnPair kernel registration, and adds focused tests for contains, prefix, suffix, exact, negated LIKE, filtered OnPair, shared OnPair, and sliced OnPair cases.
What APIs are changed? Are there any user-facing changes?

No public API changes. Query results are unchanged; supported OnPair LIKE predicates can now execute without fully canonicalizing the input first.

[codspeed-hq]

Merging this PR will degrade performance by 23.92%

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

❌ 3 regressed benchmarks
✅ 1586 untouched benchmarks
⏩ 4 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	chunked_bool_canonical_into[(1000, 10)]	16.3 µs	26.9 µs	-39.47%
❌	Simulation	slice_empty_vortex	310 ns	368.3 ns	-15.84%
❌	WallTime	cuda/bitpacked_u8/unpack/3bw[100M]	299.5 µs	346.5 µs	-13.56%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing ngates/onpair-like-pushdown (500d0a7) with develop (2a19323)}

Footnotes

1. 4 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩