GH-50539: [C++][Gandiva] size varlen cast output from the formatter

[Arawoof06]

Rationale for this change

castVARCHAR/castVARBINARY from date64 size their output block with a hard-coded 10 (YYYY-MM-DD), but the copy that follows is bounded by the caller-supplied length rather than by what was allocated. arrow::internal::StringFormatter<Date64Type> goes past 10 bytes in two ways: years outside 0-9999 need 11-12, and values it cannot represent go through detail::FormatOutOfRange, which emits up to 42 bytes.

So castVARCHAR(<date64>, 64) on an out-of-range value writes 42 bytes into a 10-byte arena block and sets out_len to 42, corrupting whatever the execution context hands out next.

The float macro has the same shape, a 24-byte constant against a formatter documented to use a 50-byte buffer, so it carries the same mismatch even though current Java-style output happens to stay under 24.

What changes are included in this PR?

The arena allocation moves inside the formatter callback, where the real formatted size is known, so the allocation and the copy use one bound. That drops the guessed constant from both the date64 and float macros.

Are these changes tested?

Yes. TestCastVARCHARFromMillisecondsLongOutput casts an out-of-range date64 and then allocates again from the same context. On the unpatched tree it reads back:

<value out12345a12345-9223372036854775808>

It passes after the change, and needs no sanitizer to fail. gandiva-internals-test, gandiva-precompiled-test and gandiva-projector-test all pass locally.

Are there any user-facing changes?

Dates and out-of-range values that format to more than 10 bytes now return the full string, truncated to the requested length, instead of writing past the block. Dates that already fit are unaffected.

This PR contains a "Critical Fix". Heap buffer overflow reachable from SQL castVARCHAR on a date64 value.

---

Disclosure of AI usage, per the AI-generated code guidance: this was produced with AI assistance, using BugQore's multi-agent redemption system. That covered locating the mismatch, writing the patch, and writing the regression test. Verified before opening: the new test fails on the unpatched tree with the corrupted output shown above and passes after, the three Gandiva suites are green, and clang-format 18.1.8 (the version pinned in .pre-commit-config.yaml) reports no changes. Happy to walk through any part of the reasoning in review.

• GitHub Issue: [C++][Gandiva] Heap buffer overflow casting date64 to VARCHAR #50539

[github-actions]

⚠️ GitHub issue #50539 has been automatically assigned in GitHub to PR creator.

[github-actions]

⚠️ GitHub issue #50539 has no components, please add labels for components.