refactor(array): allocate execution outputs through context

[gatesn]

Summary

Allocate execution outputs through the execution context.

Changes

• Propagate allocators through filter, take, interleave, and patches.
• Use context allocators in dictionary and scalar functions.
• Add tests for allocator propagation.

[codspeed]

Merging this PR will degrade performance by 5.16%

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

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

⚡ 3 improved benchmarks
❌ 8 regressed benchmarks
✅ 2186 untouched benchmarks
⏩ 218 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	WallTime	mul_u64_nonnull_neon	15.2 µs	20.9 µs	-27.21%
❌	WallTime	mul_i64_nonnull_neon	17.1 µs	20.1 µs	-15.02%
❌	WallTime	multiply_shapes_neon[(16384, PerRowPerRow)]	17.1 µs	20.1 µs	-14.68%
❌	WallTime	dict_canonicalize_gt_u8_avx2[16000000]	7 ms	8.2 ms	-14.37%
❌	Simulation	take_search[(0.005, 0.05)]	19.8 µs	22.8 µs	-13.37%
❌	Simulation	take_search[(0.01, 0.05)]	20.5 µs	23.6 µs	-13.14%
❌	WallTime	dict_canonicalize_gt_u8_avx2[1000000]	427.7 µs	481.1 µs	-11.1%
❌	Simulation	take_search[(0.005, 0.1)]	26.1 µs	29.1 µs	-10.31%
⚡	WallTime	arrow_checked_add_u32_neon[16384]	20.4 µs	13.4 µs	+52.9%
⚡	WallTime	filtered_owned_i64_avx512[OneNullInEight]	26.3 µs	22.1 µs	+18.76%
⚡	Simulation	allocate_drop_arrow[0]	456.9 ns	402.7 ns	+13.45%

Tip

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

---

_{Comparing ngates/buffer-allocator-execution (ed0df23) with develop (ad925fd)²}

Footnotes

1. 218 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. No successful run was found on develop (ed4d347) during the generation of this report, so ad925fd was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[robert3005]

Is there some follow up for other crates? I think you want to forbid in the codebase the non allocator taking methods which you can do via clippy lint

[gatesn]

On workspace-wide enforcement: #9672 was the original follow-up, but its targeted regex checker was the wrong mechanism and was closed. Clippy disallowed-methods is workspace-wide, so enabling it for the convenience constructors now would also reject intentional uses outside allocator-aware execution, including vortex-buffer itself. I agree that a workspace migration followed by a Clippy rule is the right endpoint, but it should remain a separate change. This PR keeps the public convenience APIs while making execution allocations explicit and hiding retained allocator access from buffer callers.