Grouped floating-point `MIN` and `MAX` return order-dependent results for NaNs and signed zeros

[Theodus]

Describe the bug

The optimized grouped accumulators for floating-point MIN and MAX use partial_cmp rather than the total ordering used by the non-grouped accumulators. Comparisons with NaN return None, causing the grouped update to overwrite the current value. The partial ordering also considers +0.0 and -0.0 equal, retaining whichever occurs first.

As a result, grouped MIN and MAX can return different results depending on input order, batching, or partitioning.

This bug was discovered after special floating-point values were added to the aggregation fuzz data in #24433.

To Reproduce

For one group, the optimized grouped accumulators produce these incorrect results (NaN is positive):

MAX([NaN, 1.0])   = 1.0
MIN([1.0, NaN])   = NaN
MAX([-0.0, +0.0]) = -0.0
MIN([+0.0, -0.0]) = +0.0

Reordering the same inputs changes the results.

Expected behavior

Grouped and non-grouped MIN/MAX should use the same deterministic total ordering for floating-point values. Under the ordering already used by ScalarValue and the non-grouped accumulators:

MAX([NaN, 1.0])   = NaN
MIN([1.0, NaN])   = 1.0
MAX([-0.0, +0.0]) = +0.0
MIN([+0.0, -0.0]) = -0.0

Results should not depend on row order, batch boundaries, or partitioning.

Additional context

The grouped Float16, Float32, and Float64 accumulators should use total_cmp, matching the non-grouped implementation. Their initial values must also be the extrema of the total ordering: the finite MIN/MAX constants are not valid identities when infinities and NaNs are included.