fix: report Parquet Bloom filter pruning metrics accurately

[rgbuilds]

Which issue does this PR close?

• Closes Improve parquet row group pruning metrics display #18355.

Rationale for this change

row_groups_pruned_bloom_filter currently reports retained row groups as Bloom filter matches even when Bloom pruning was not evaluated—for example, when Bloom filters are disabled or unavailable, no relevant Bloom statistics were loaded, or predicate evaluation failed.

This makes EXPLAIN ANALYZE suggest that Bloom filters evaluated and matched row groups when they did not participate in the pruning decision. It also displays an idle Bloom pruning metric when all its counters are zero.

A retained row group is not necessarily a Bloom filter match. The metric should describe actual Bloom pruning outcomes.

What changes are included in this PR?

• Record a Bloom filter match only when the Bloom pruning predicate is successfully evaluated and determines that the row group may match.
• Leave Bloom pruning counters unchanged when Bloom pruning is unavailable or cannot be evaluated.
• Continue retaining row groups conservatively when Bloom predicate evaluation fails, while recording the failure in predicate_evaluation_errors.
• Omit row_groups_pruned_bloom_filter from physical-plan displays when all of its pruning counters are zero.
• Preserve the registered metric and direct metric lookup; only its accounting and displayed output change.
• Update affected Rust assertions and SQL logic test snapshots.

The row-group access decisions and query results are unchanged.

What is the testing strategy for this PR?

Added bloom_filter_pruning_error_retains_row_group_without_match, which verifies that a Bloom predicate evaluation error:

• retains the row group;
• increments predicate_evaluation_errors;
• does not increment either the Bloom matched or pruned counter.

The display tests verify that:

• an idle Bloom pruning metric is omitted from aggregated and full Indent, Graphviz, and PostgreSQL JSON output;
• unrelated zero-valued metrics remain visible;
• genuine nonzero Bloom pruning results remain visible.

The following existing test coverage was also run:

• Parquet Bloom-filter and row-group-filter unit tests;
• parquet_integration row-group-pruning tests;
• core_integration explain-analyze tests;
• physical-plan display tests;
• affected SQL logic tests for dynamic filtering, dynamic row-group pruning, explain-analyze, limit pruning, and Parquet filter pushdown.

Formatting checks also pass.

Are there any user-facing changes?

Yes. Parquet Bloom filter pruning metrics in EXPLAIN ANALYZE and other physical-plan displays more accurately represent actual Bloom filter evaluation. An entirely idle row_groups_pruned_bloom_filter metric is no longer displayed.

There are no public API changes and no changes to query results or row-group access decisions.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 89.67552% with 35 lines in your changes missing coverage. Please review.
✅ Project coverage is 82.73%. Comparing base (6f3f7b7) to head (278c7db).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
datafusion/physical-plan/src/display.rs	88.50%	33 Missing ⚠️
datafusion/datasource-parquet/src/opener/mod.rs	88.88%	2 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff            @@
##             main   #25822    +/-   ##
========================================
  Coverage   82.72%   82.73%            
========================================
  Files        1147     1147            
  Lines      448179   448437   +258     
  Branches   448179   448437   +258     
========================================
+ Hits       370751   371004   +253     
- Misses      54898    54904     +6     
+ Partials    22530    22529     -1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[rgbuilds]

Rebased onto current main and updated the accounting for the fully matched row-group path introduced by #25854.

Extended the existing scan test to verify Bloom matched/pruned counters for statistics-disabled, mixed, and entirely fully matched cases. Restoring the previous increment makes the mixed-case assertion fail.

Focused Bloom, row-group, display, and affected SQL logic tests pass locally, along with formatting checks.

[rgbuilds]

@xudong963 Thanks for approving the earlier workflow runs. I’ve since updated the Bloom accounting for the fully matched path introduced by #25854 and added regression tests. Fork CI is green on 22cf2a2; the upstream workflows are awaiting approval again. Could you please approve the latest runs when convenient?

[xudong963]

THanks for the fix, solid fix

[rgbuilds]

@xudong963 Thanks for reviewing and approving! Could you please merge this when convenient?

[xudong963]

@xudong963 Thanks for reviewing and approving! Could you please merge this when convenient?

Plan to leave it for two days to see if others wanna have a look

[rgbuilds]

@xudong963 Thanks for reviewing and approving! Could you please merge this when convenient?

Plan to leave it for two days to see if others wanna have a look

Makes sense.

[rgbuilds]

@xudong963 I rebased onto current main and fixed the merge-queue failure in dynamic_row_group_pruning.slt. The relevant tests and extended suite pass locally. The new upstream workflow runs are awaiting approval again — could you please approve them when convenient? Thanks!