fix: reassign predicate column indices by name before building pruning predicates

[radustoenescu]

Problem

ParquetSource::try_pushdown_filters (and other producers of self.predicate) can store a filter whose Column carries an index that is only valid for the schema it was originally built against. In particular, when a join's filter-pushdown/inference produces a filter for one side from a condition on the other side, the resulting Column keeps the name of the join key but can keep the other side's index.

build_pruning_predicates (used both by the real per-file pruning path and by ParquetSource::fmt_extra's Display output) uses that predicate's Column indices as-is against file_schema. When the index happens to land on a differently-typed column (e.g. a leading struct-typed column), this can panic in debug builds:

PhysicalExprSimplifier::simplify runs a debug-only type-preservation assertion (node.data_type(schema).unwrap()) before/after each rewrite. Resolving the mismatched Column by its (wrong) index against file_schema produces a type-coercion error (e.g. Struct(..) = Float64), and the .unwrap() panics.

This is most visible via Display (EXPLAIN, logging, or any code that displays the plan) because that path does not go through per-file schema adaptation the way the real execution path does - the real path (ParquetOpener::open) is protected by whatever PhysicalExprAdapter is configured, which re-resolves columns by name before anything type-sensitive runs. fmt_extra has no such adapter available (it doesn't have the per-file physical schema), so it's exposed to the raw, possibly-mismatched predicate.

Fix

In build_pruning_predicates, reassign every Column's index by name against file_schema before building the pruning/page-pruning predicates, using the existing reassign_expr_columns helper (datafusion_physical_expr::utils::reassign_expr_columns), which is already used elsewhere in this crate for the same purpose (row_filter.rs, opener.rs). This is a 4-line change and makes build_pruning_predicates robust regardless of which producer handed it a stale-indexed predicate.

Test

Added test_display_does_not_panic_on_predicate_with_mismatched_column_index in source.rs: builds two real parquet-backed ParquetSources (one with a leading struct column, matching the real-world shape that triggered this), joins them via HashJoinExec, and attaches to one side a Column-mismatched predicate wrapped in a DynamicFilterPhysicalExpr (matching the shape that makes PruningPredicate::try_new take its snapshot/simplify path). Asserts displayable(...).to_string() does not panic.

Verified:

• Fails with the exact original panic message (Cannot infer common argument type for comparison operation Struct(..) = Float64) when the fix is reverted.
• Passes with the fix applied.
• Full crate test suite (cargo test -p datafusion-datasource-parquet) and full workspace test suite (cargo test --workspace) pass with the fix applied, no regressions.