Avoid row index canonicalization for trivial masks

[danking]

Summary

• skip row-index filtering/canonicalization when the scan mask is all true, preserving the SequenceArray through expression application
• return an empty u64 canonical array directly for all-false masks
• add regression coverage for the all-true and all-false row index array future paths

Stacked on #9720, which handles unsigned SequenceArray export for DuckDB.

Tests

• cargo +nightly fmt --all
• cargo test -p vortex-layout row_idx_array -- --nocapture
• cargo test -p vortex-layout layouts::row_idx -- --nocapture
• cargo clippy -p vortex-layout --all-targets --all-features
• cargo test -p vortex-sqllogictest --test sqllogictests -- slt::duckdb::duckdb/projection_expression_pushdown.slt --nocapture

[codspeed-hq]

Merging this PR will degrade performance by 4.73%

⚠️ 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 improved benchmarks
❌ 3 regressed benchmarks
✅ 2085 untouched benchmarks
⏩ 206 skipped benchmarks¹
🗄️ 4 archived benchmarks run²

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	WallTime	arrow_checked_add_u32_neon[16384]	13.4 µs	20.3 µs	-34.28%
❌	Simulation	cached_indices_i128[0.01]	48.1 µs	61.7 µs	-22.04%
❌	Simulation	compress_fsst[(500, 64, 8)]	482.1 µs	536.2 µs	-10.09%
⚡	Simulation	cached_indices_i32[0.01]	51.6 µs	37.5 µs	+37.4%
⚡	WallTime	words_gather_scalar_avx512[1024]	124 ns	100 ns	+24%

Tip

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

---

_{Comparing dk/row-idx-mask-sequence-fast-path (130193d) with develop (e7512cf)³}

Footnotes

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

2. 4 benchmarks were run, but are now archived. If they were deleted in another branch, consider rebasing to remove them from the report. Instead if they were added back, click here to restore them. ↩

3. No successful run was found on develop (e3923a5) during the generation of this report, so e7512cf was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[danking]

Need to fix duckdb exporter first.

[robert3005]

why do we do this here? why not just return filtered?