fix: validate window ordering before removing sort - #26858

Which issue does this PR close?

Closes #26772

Rationale for this change

A query involving nested window functions can fail with a SanityCheckPlan ordering error when a grouping expression is derived from a column constrained by a WHERE equality filter.

In the reported case, a DENSE_RANK() window ordered by (total DESC, k) operates on the result of a SUM() window partitioned by k, where k is derived from lower(g) and g is filtered to a constant value.

Although the query is valid, DataFusion generates a physical plan that does not satisfy the outer window's required ordering, causing execution to fail.

This change ensures that such queries can execute successfully.

What changes are included in this PR?

• Added input ordering validation in adjust_window_sort_removal() before accepting a replacement window operator.
• Used the child plan's equivalence properties to check whether the replacement window's required ordering is satisfied.
• If the ordering is not satisfied, the existing fallback inserts the required SortExec.
• Added a SQL regression test reproducing the original failure.

The change preserves the existing window-sort optimization when the replacement window's ordering requirements are satisfied.

What is the testing strategy for this PR?

Added test_window_ordering_constant_group_key_26772 in datafusion/core/tests/sql/window_ordering_26772.rs.

The test reproduces the reported issue using nested SUM() and DENSE_RANK() window functions, a filtered grouping expression, and target_partitions = 1.

Before the fix, the test fails with a SanityCheckPlan ordering error. After the fix, the query executes successfully and returns the expected result (k = 'a', r = 1).

Validation performed:

• cargo test -p datafusion --test core_integration test_window_ordering_constant_group_key_26772 — passed (1 test).
• cargo test -p datafusion-physical-optimizer — passed (41 tests).
• cargo fmt --all -- --check — passed.
• git diff --check — passed.

Are there any user-facing changes?

Yes. Queries affected by the incorrect window sort removal now execute successfully instead of failing with a SanityCheckPlan error.

There are no intended changes to SQL syntax, public APIs, or existing query semantics. No documentation updates are required.