refactor(array): propagate allocators through builders

[gatesn]

Summary

Require every array builder caller to choose its buffer allocator explicitly.

Changes

• Replace implicit and _in constructor pairs with one allocator-taking API.
• Borrow allocator handles at API boundaries; clone only when a buffer or builder retains them.
• Propagate the allocator through nested, dictionary, and offset-based string builders.
• Use ctx.allocator() in execution paths; use the static allocator only where no execution context exists.
• Add custom allocator coverage.

[codspeed-hq]

Merging this PR will regress 1 benchmark

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

⚡ 5 improved benchmarks
❌ 1 regressed benchmark
✅ 2166 untouched benchmarks
⏩ 206 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)]	27.1 µs	30.8 µs	-12.25%
⚡	WallTime	arrow_checked_add_u32_neon[16384]	20.5 µs	12.8 µs	+59.85%
⚡	Simulation	decompress[u64, (4000, 1024)]	85.6 µs	71.2 µs	+20.3%
⚡	Simulation	allocate_drop_arrow[0]	456.9 ns	402.7 ns	+13.45%
⚡	Simulation	compact_sliced[(1024, 90)]	1.5 µs	1.4 µs	+12.03%
⚡	Simulation	compact_sliced[(2048, 90)]	1.6 µs	1.4 µs	+11.53%

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-builders (69a9f2e) with develop (792cef7)}

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

[robert3005]

No breaks please, can you add back old api and mark it deprecated. Users don't want the churn just because you need a new feature.

[gatesn]

I dunno… most callers will have an ExecutionCtx in scope and not pass it. In fact, shouldn't ArrayBuilders hold ExecutionCtx anyway so that you can extend_from_array?

[robert3005]

I am purely arguing from the churn POV, it would be ideal if we can avoid forcing people to update their builder usage when they upgrade vortex. I think we can remove it in 1-2 releases