[rank-p]

Which issue does this PR close?

Closes #15812. Related to #26490.

Rationale for this change

Parquet float min/max can exclude NaNs. Treating these as complete bounds can discard matching rows, remove necessary filters, return incorrect MIN/MAX, or replace [1.0, NaN] with [1.0, 1.0].

This draft is a count-aware alternative to #24804, which withholds all float bounds. It keeps bounds when the existing metadata proves they are safe. I am proposing it separately to discuss that distinction and the fallback cost before changing the pruning API. Related approaches are the closed #15821 and the narrower constant-column fix in #27283.

What changes are included in this PR?

• Validate float bounds when exposing file, row-group, and page statistics.
• Require matching stored/output float types, IEEE total order, and proof of zero NaNs. Missing counts are unknown. Page counts take priority, with a known-zero group count covering missing page counts.
• Withhold unsafe bounds while keeping unrelated statistics.

No public API changes (so far).

What is the testing strategy for this PR?

Regressions, SQL and DataFrame tests

Are there any user-facing changes?

Queries return correct values, but affected min/max optimizations are lost for unknown/positive NaN counts, TYPE_ORDER floats (even with zero NaNs), and float schema casts.

This can potentially be a large cost. Suppose a row group containing [10, 20, NaN] with metadata min = 10, max = 20, unknown NaN count and a filter like WHERE x >= 100 AND x < 200.
With this approach, we make no use of the min/max statistics (not skipping the row group) even though the we can prove that the NaN count is irrelevant for this kind of WHERE clause.

This can be fixed. But before spending time on this optimization I first wanted to get some general feedback on the approach, since it appears there are multiple people working on it

AI Disclosure: Codex