Define experimental RowFn contracts

[connortsui20]

Rationale for this change

• Tracking issue: Tracking Issue: Define the RowFn API #9129
• Epic: Epic: Row-oriented scalar functions #9128
• Execution tracking: Tracking Issue: Execute RowFn over Vortex arrays #9130

Defines the unstable author-facing RowFn contracts. The execution backend is split into #9353.

What changes are included in this PR?

Adds the unstable_row_fns feature boundary, RowFn and visitor traits, typed input and output contracts, tuple adapters, planning, and the blanket ScalarFnVTable scaffold. execute_rows remains a temporary error until #9353 adds the backend.

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

Adds vortex_array::scalar_fn::unstable::row behind the non-default unstable_row_fns feature. The API has no compatibility guarantees.

[codspeed-hq]

Merging this PR will degrade performance by 11.89%

⚠️ 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.

❌ 2 regressed benchmarks
✅ 1992 untouched benchmarks
⏩ 89 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	compress_fsst[(1000, 64, 8)]	1 ms	1.2 ms	-11.94%
❌	WallTime	words_gather_scalar[65536]	8.3 µs	9.4 µs	-11.83%

Tip

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

---

_{Comparing ct/row-fn-types (da08e03) with develop (c17e058)}

Footnotes

1. 89 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. ↩

[joseph-isaacs]

Can we name this differently to plan. Its more like a Execution Receiver (or accept)?

[connortsui20]

I feel like these names are not that much better, really what we want to express is that it is almost like a type checking phase, but it also verifies the flags.

Maybe VerifyRows or VerifyVisitor or something similar?

[joseph-isaacs]

Sure just not plan

[connortsui20]

Actually no it does do more than verification, it plans how to execute everything (do we use dense, do we prefilter, how do we handle errors, etc). Though I agree that plan can be a bit misleading