[SPARK-56944] [SQL] Trim aliases from ListAgg expression subtree

[mihailoale-db]

What changes were proposed in this pull request?

In this PR I propose to trim aliases from ListAgg expression subtree in order to fix a discrepancy between single-pass and fixed-point analyzers.
It is a safe change since it would otherwise be removed in CleanupAliases.

Why are the changes needed?

To fix a dual-run issue.

Does this PR introduce any user-facing change?

No.

How was this patch tested?

Added + existing tests.

Was this patch authored or co-authored using generative AI tooling?

Yes.

[mihailoale-db]

@cloud-fan PTAL when you find time. Thanks!

[cloud-fan]

Thanks Mihailo, the fix is reasonable and follows the pattern from SPARK-54871.

One question about completeness, and one about test coverage — see inline. Otherwise the change is straightforward.

[cloud-fan]

The PR description says "trim aliases from ListAgg expression subtree", but checkOrderValueDeterminism (line 684) still does orderExpressions.head.child.semanticEquals(castChild) without trimming. With spark.sql.listagg.allowDistinctCastWithOrder.enabled=true (default), a query like

SELECT listagg(DISTINCT v:a::string, ',') WITHIN GROUP (ORDER BY v:a) FROM ...

reaches that path, and the two analyzers still produce different errors:

• single-pass (aliases still present): the Alias-vs-Alias semanticEquals is false because the ExprIds differ, so we return NonDeterministicMismatch and throw functionAndOrderExpressionMismatchError.
• fixed-point (post-CleanupAliases): semanticEquals is true, then isCastEqualityPreserving(VariantType) is false, so we throw functionAndOrderExpressionUnsafeCastError.

Should this comparison also wrap both sides in trimAliases? Otherwise the single-pass/fixed-point divergence is only partly closed.

[cloud-fan]

SQLQueryTestSuite only runs the legacy analyzer here, where CleanupAliases has already stripped the parser-introduced Alias before CheckAnalysis calls isOrderCompatible. So these golden files pass on master without the fix too — they don't actually exercise the single-pass path the PR is fixing.

Consider adding a targeted single-pass unit test (e.g. in AggregateExpressionResolverSuite or alongside ResolverRunner) that constructs LISTAGG(DISTINCT v:a::string) WITHIN GROUP (ORDER BY v:a::string) and goes through Resolver directly, so the regression is pinned at the layer where it actually manifested.