Restore Sort unparser guard for correct ORDER BY placement

[krinart]

Which issue does this PR close?

• closes Incorrect ORDER BY in unparser after DF 52 upgrade #20905
• closes Restore Sort unparser guard for correct ORDER BY placement (v2) #20923

Restore the already_projected() guard in the Sort case of select_to_sql_recursively. Without it, queries with ORDER BY expressions generate invalid SQL when the Sort node follows an outer Projection.

Problem

Two regressions in the DuckDB federation unparser after upgrading to DataFusion 52:

1. clickbench q25: Queries like SELECT "SearchPhrase" ... ORDER BY to_timestamp("EventTime") LIMIT 10 produce ORDER BY outside the subquery, referencing table names ("hits") that are out of scope.
2. tpcds q36: ORDER BY with GROUPING() expressions loses the derived_sort subquery alias, placing sort references outside their valid scope.

Root Cause

DF52's optimizer merges Limit into Sort as a fetch parameter, changing the plan shape from Projection → Limit → Sort → ... to Projection → Sort(fetch) → .... The Sort case previously had a guard that wrapped the sort into a derived_sort subquery when already_projected() was true. This guard was removed in DF52, causing ORDER BY and LIMIT to be placed on the outer query where inner table references are invalid.

Fix

Re-add the guard at the top of the Sort match arm in select_to_sql_recursively:

 if select.already_projected() {
     return self.derive_with_dialect_alias("derived_sort", plan, relation, false, vec![]);
 }

[alamb]

Thanks @krinart

[alamb]

I think this is the same as https://docs.rs/datafusion/latest/datafusion/logical_expr/enum.Expr.html#method.unalias_nested

[alamb]

It apparently isn't quite the same, but I am not sure if the different matters. Let's leave it like this

[krinart]

I tried to use it here - but test_complex_order_by_with_grouping test failed.

[alamb]

@krinart -- this PR also has some conflicts that need to be resolved

Maybe you can also address the comment as well? I would like to backport this to the 52 branch for the next patch release

[alamb]

I also filed #20905 to track this issue so we can merge it back to 52

[alamb]

We are trying to prepare a 52 and 53 release, and since this issue is a regression I would like to fix it today. I can't push to your branch (as it is in the spiceai fork) so I will likely open a new PR to get it ready

[alamb]

Here is a proposed fix: #20923

[alamb]

No worries, thank you @krinart -- I reopened this PR and as it is approved I'll merge it when it passes

[alamb]

Hi @krinart -- there appears to be a few test failures. Any chance you can resolve them (You can use the changes on #20923 as a guide)