[format] Drop ORC float bounds that hide NaN or -0.0 - #10337

[P1] The signed-zero fix still skips positive zero when ORC reports a negative-zero upper bound.

On head c52330babf7b12668472001388daab973a2f06c0, OrcSimpleStatsExtractor.orcFloatingPointBoundsUnusable (line 261) only rejects a +0.0 minimum. Writing [-1.0, -0.0, +0.0] to a real ORC append table produces footer and manifest bounds min=-1.0, max=-0.0, with a finite sum, so this guard accepts the unsafe maximum. An unfiltered read preserves the positive-zero row, but ReadBuilder.withFilter(equal(v, +0.0)) and greaterThan(v, -0.0) both plan zero splits and return no rows. I reproduced this for FLOAT and DOUBLE, with the default write batch size 1024, before and after an actual COMPACT commit. With two input files, the row-level oracle contains two matching rows in both cases.

There is also a second pruning layer: in an isolated control that additionally rejects max=-0.0, the plan retains the file, but ORC SearchArgument row-group filtering still returns zero rows. Only the combined control—dropping the unsafe upper bound and declining signed-zero predicate pushdown in OrcPredicateFunctionVisitor—returns the expected rows. Please cover both layers with actual table-read regression tests; an extractor-only assertion does not verify the required end-to-end behavior.

This is a remaining case of the existing bug described by #10334, not a new regression introduced by this PR. The current patch fixes the NaN cases in the same comparison, but leaves this signed-zero case unresolved. Validation: all 30 normal JDK 8 tests passed (OrcFloatingPointStatsTest, OrcSimpleStatsExtractorTest, OrcFormatReadWriteTest, AppendOnlyTableFileMetaFilterTest); the additional real-ORC matrix has 240 predicate queries, with 8 failures on this head and zero failures in the combined control. No production storage or credentials were used.