fix(backport): prevent array_resize capacity overflow panic

[discord9]

Which issue does this PR close?

• Backports the fix for panic: array_resize capacity overflow with large target size apache/datafusion#22227 (upstream fix: return execution error instead of capacity overflow panic in array_resize apache/datafusion#23306, commit 8272b4aa).

Rationale for this change

array_resize(make_array(1), 9223372036854775807, 0) panics while creating the physical plan on the GreptimeDB DataFusion 53.1 fork. Oversized resize requests should return a controlled execution error instead of aborting query planning.

What changes are included in this PR?

• Preflight cumulative output lengths before materializing fill values or allocating Arrow buffers.
• Reject totals that overflow the list offset type or Arrow 58 eager buffer capacities, including alignment and nested-capacity constraints.
• Preserve the fork's existing NULL-count and row-specific fill behavior while replacing target-derived unchecked offset arithmetic.
• Add allocation-safe unit coverage plus an ignored process-isolated witness for the original huge input.

The eager allocation limits cannot prove arbitrary variable-width payload bytes or variable nested-child cardinality copied during extend; those remain data-dependent. No public API or dependency changes are included.

Are these changes tested?

Using the supplied shared target and sccache:

• cargo fmt --check
• git diff --check
• cargo test -p datafusion-functions-nested --no-fail-fast (57 passed, 1 ignored; 2 doctests passed)
• cargo test -p datafusion-functions-nested resize::tests::array_resize_huge_size_returns_controlled_error -- --ignored --exact (passed)
• cargo clippy -p datafusion-functions-nested --all-targets -- -D warnings
• cargo check -p datafusion-functions-nested

The pre-fix isolated GreptimeDB witness reproduced the panic 4/4 while its small array_resize([1], 3, 0) control succeeded.

Are there any user-facing changes?

Yes. Oversized array_resize requests now return an execution error containing exceeds the maximum array size instead of panicking. There are no API changes.