[AURON #2517] Align native float ordering with Spark

[Sigma-Ma]

Which issue does this PR close?

Closes #2517

Rationale for this change

Native floating-point comparisons and min/max aggregations return different results from Spark for NaN and signed zero. Spark treats NaN as greater than non-NaN values and considers -0.0 equal to 0.0.

What changes are included in this PR?

• Normalize NaN and signed zero before native Float/Double comparisons.
• Apply Spark-compatible float ordering in native min/max partial updates and merges.
• Add Rust regression tests and Spark-versus-native comparison tests.

Are there any user-facing changes?

Yes. Native Float/Double comparisons and min/max results now match Spark for these edge cases.

How was this patch tested?

• cargo test -p datafusion-ext-plans --lib --locked
• cargo fmt --all --check
• ./dev/reformat --check
• ./build/mvn -pl spark-extension-shims-spark -am install -DskipTests -Ppre -Pspark-3.5 -Pscala-2.12
• ./build/mvn -pl spark-extension-shims-spark test -DskipBuildNative -Ppre -Pspark-3.5 -Pscala-2.12 -Dsuites=org.apache.auron.AuronFunctionSuite

Was this patch authored or co-authored using generative AI tooling?

• Yes
• No

Generated-by: OpenAI Codex (GPT-6)

[slfan1989]

Could we preserve predicate pruning when adding these normalization wrappers?

This code also runs with isPruningExpr = true, so even a simple floating-point filter such as d > 100.0 becomes a comparison between scalar function expressions.

The current Parquet pruning logic cannot rewrite the wrapped column expression, and the ORC converter requires a direct Column/Literal comparison.

[Sigma-Ma]

Thanks for catching this. I kept normalization in normal float comparison evaluation while preserving direct column/literal expressions for scan pruning. Testing also exposed an ORC case where d > 100.0 could incorrectly prune a row group containing NaN, so the ORC patch now keeps row groups when their float statistics are uncertain. I added Float/Double converter and Parquet/ORC scan regressions.

[Sigma-Ma]

The Spark 3.0 and 3.1 failures came from the ORC Spark baseline dropping NaN for d > 100.0. Auron returned the expected NaN row. I updated the regression test to assert that result and native execution directly.