Fix DuckDB unparse for optimized join projections

[goutamadwant]

Which issue does this PR close?

• Closes Optimized logical plans produce invalid DuckDB SQL #22961.

Rationale for this change

Optimized plans can introduce intermediate projection aliases from common subexpression elimination and can also leave join conditions referencing aliases from a flattened join input.

The SQL unparser was rebasing some unqualified optimizer aliases to a table alias, producing invalid references such as "o"."__common_expr_1". It could also emit a derived projection around a join input while the outer join condition still referenced aliases inside that derived table, producing SQL that DuckDB rejects.

What changes are included in this PR?

• Make TableAliasRewriter use DFSchema qualifier information instead of only Arrow field names, with explicit control over whether unqualified fields should be rebound to a table alias.
• Keep existing alias rebasing for table-scan filters and window-derived inputs.
• Avoid wrapping qualified pass-through join projections when they are used as the left input of another already projected join, so referenced aliases remain in scope.
• Add a regression test for the optimized DuckDB unparse path from the issue.

Are these changes tested?

• cargo fmt --all
• cargo test -p datafusion --test core_integration optimized_duckdb_unparse_preserves_derived_table_scope
• cargo test -p datafusion-sql --test sql_integration
• cargo test -p datafusion-sql unparser::rewrite
• cargo clippy -p datafusion-sql --test sql_integration -- -D warnings
• cargo clippy -p datafusion --test core_integration -- -D warnings

Are there any user-facing changes?

No public API changes. This fixes SQL generated by the unparser for optimized logical plans.

[kosiew]

@goutamadwant
Thanks for working on this fix. I think there's still one correctness gap around the symmetric join case, plus a small cleanup opportunity in the rewrite logic.

[kosiew]

Nice catch on the derived-join-input case for the left side. I think the same invariant applies symmetrically to the right side as well.

Right now unwrap_qualified_passthrough_join_projection is only applied to left_plan. If the optimized plan contains a qualified passthrough Projection(Join) on the right input while already_projected is true, we'll still recurse into that projection, emit it as a derived table, and then join_constraint_to_sql will use join.on columns that refer to aliases defined inside the derived table.

That seems to reintroduce the invalid-scope SQL this PR is fixing, but for right-deep or nested-right join shapes. Could we apply unwrap_qualified_passthrough_join_projection to right_plan as well before building right_relation and add a regression test covering a nested join on the right side?

[kosiew]

Small cleanup suggestion: both rewrite arms construct the same replacement column.

It might read a bit more clearly if the match made the rewrite condition explicit, something along the lines of Ok((qualifier, field)) if qualifier.is_some() || self.rewrite_unqualified, and then performed the rewrite once. The remaining Ok((None, _)) | Err(_) arm could stay as the no-op path. That would remove the duplicated Column::new(...) construction.

[goutamadwant]

Thanks for the review @kosiew I pushed an update addressing both comments.

For the symmetric right-side case, the unparser now emits a qualified passthrough Projection(Join) as a parenthesized nested join relation instead of a derived projection. That keeps the inner join aliases visible to the outer join condition without reintroducing the invalid alias scope.

I also added a regression test for the right-side nested join case and simplified TableAliasRewriter so the rewrite condition is expressed once and the replacement column is constructed once.

Ran locally all the tests and they look fine. Let me know if you any suggestions. thanks!