[alexanderbianchi]

Which issue does this PR close?

No linked issue; reproducer below.

Rationale for this change

A key filter inside a join input is not propagated to the other side of an equi-join:

CREATE TABLE a (k VARCHAR);
CREATE TABLE b (k VARCHAR);
INSERT INTO a VALUES ('k1'), ('k2');
INSERT INTO b VALUES ('k1'), ('k2');

EXPLAIN SELECT *
FROM (SELECT * FROM a WHERE k = 'k1') a
JOIN b ON a.k = b.k;

Previously, only a received the static filter. This change also derives b.k = 'k1', allowing it to be pushed toward the other scan. It also handles predicates pushed below joins by an external planner.

What changes are included in this PR?

Extend PushDownFilter inference to use deterministic predicates from inner-join inputs, through column projections and aliases. Preserve the original predicates and avoid adding ones already guaranteed by the destination. Scan predicates are used only when the provider reports exact pushdown.

What is the testing strategy for this PR?

SQL regressions cover both directions, CTEs/aliases, multiple keys, ranges, NULL-safe equality, LIMIT, repeated passes, and conservative handling of computed keys, volatile predicates and outer joins. A provider-level test covers exact versus inexact scan filters and optimizer idempotence. Existing Parquet plan expectations now verify that the inferred static filter reaches the other scan alongside its dynamic filter.

Local validation: the required extended workspace suite passes (13,451 Rust tests and 547 SQL test files), along with formatting and all-targets/all-features Clippy with warnings denied. The existing filter-pushdown planner benchmark detected no significant change against the base commit (local ci profile).

Are there any user-facing changes?

Filtered inner joins can now apply additional static filters before reading the other input. No public API changes.