Reserve computed hash join build keys before allocating the hash map #26805

Is your feature request related to a problem or challenge?

In build_in_memory (datafusion/physical-plan/src/joins/hash_join/exec.rs), the build-side join keys are evaluated with evaluate_expressions_to_arrays(on_left, &batch), but their memory is only reserved further down, together with the normalized float keys (keys_size, then reservation.try_grow(keys_size)).

For plain column keys this costs nothing, since the arrays share the build batch's buffers. For computed keys (for example ON a + 1 = b), the arrays are new allocations that exist before they are reserved. With #26793 the keys are evaluated before the hash map is allocated, so they are now unaccounted while new_join_hashmap reserves and allocates the map, not just for the few lines before try_grow. A pool that is close to full can end up a little over its limit for that span.

Describe the solution you'd like

Split the reservation: try_grow the left_values share right after the keys are evaluated, before the map is chosen and allocated, and reserve only the normalized_values share after the branch. RecordBatchMemoryCounter already skips buffers shared with the batch, so the two shares can be counted in two steps. A test could use a computed key and a pool limit that fits the keys only if they are reserved first.

Describe alternatives you've considered

Leave it as is. The overshoot is bounded by the size of the computed key arrays, and it only happens when keys are computed rather than columns.

Additional context

Came up in review of #26793 (follows #26792).

Willingness to contribute

I cannot contribute to this feature at this time