fix: preserve input ordering required by limits

[jayhan94]

Which issue does this PR close?

• Closes Returns the wrong grouped row when an outer GROUP BY consumes a subquery containing ORDER BY ... OFFSET. #23534.

Rationale for this change

EnsureRequirements may remove a descendant SortExec when the child has no visible output ordering.

This is incorrect at a LIMIT boundary because LIMIT and OFFSET depend on the input sequence to determine which rows are returned. When an intervening ProjectionExec removes the sort key, its output_ordering() becomes None, even though it still preserves the row sequence. The optimizer then incorrectly removes the sort below the projection, producing incorrect results.

What changes are included in this PR?

• Prevent EnsureRequirements from removing a linked SortExec at a limit boundary.

• Add a SQL regression test that verifies the correct row is selected by an ordered subquery with OFFSET.

• Configure the regression test with one logical optimizer pass to ensure correctness does not depend on a later logical rewrite.

No public API changes are included.

Are these changes tested?

Yes. The regression test fails without the fix, returning sorted_first instead of physical_second.

The following checks were run:

cargo test -p datafusion --test core_integration \
  ordered_offset_subquery_preserves_selected_row -- --nocapture

cargo fmt --all

cargo clippy --all-targets --all-features -- -D warnings

RUST_BACKTRACE=1 cargo test --profile ci \
  --exclude datafusion-examples \
  --exclude datafusion-benchmarks \
  --exclude datafusion-cli \
  --workspace --lib --tests --bins \
  --features
  avro,json,backtrace,extended_tests,recursive_protection,parquet_
  encryption

Are there any user-facing changes?

Yes. Ordered subqueries followed by LIMIT or OFFSET now preserve the sort needed to select the correct rows when an intervening projection hides the sort key.

There are no public API or documentation changes.

[jayhan94]

@alamb PTAL🙏

[alamb]

Thanks for this PR @jayhan94

[alamb]

This property seems like it is some internal invariant of EnforceDistribution rather than something that describes how the ExecutionPlan behaves

I don't think we should add this to the ExecutionPlan trait

[alamb]

Isn't LIMIT already handled for subqueries? Perhaps we just need to extend the same logic to handle OFFSET

I don't understand the need to add a new method to ExecutionPlan

[jayhan94]

Isn't LIMIT already handled for subqueries? Perhaps we just need to extend the same logic to handle OFFSET

I don't understand the need to add a new method to ExecutionPlan

I tried extending PushDownLimit for OFFSET, but correctness still depended on optimizer pass order. With one pass, Limit → Projection → Sort remains and EnsureRequirements incorrectly removes the sort. So, I simplified the patch: no ExecutionPlan API changes—just use the existing is_limit check to preserve linked sorts below a limit, with a regression test proving the fix. Please review again @alamb.