fix: sort pushed below GlobalLimitExec ignores skip, returning too few rows

[jayzhan211]

Which issue does this PR close?

• Closes #.

Rationale for this change

ORDER BY applied on top of a LIMIT ... OFFSET subquery returns too few rows.

SELECT * FROM (SELECT a FROM t1 LIMIT 4 OFFSET 3) ORDER BY a;

EnforceSorting pushes the sort below the GlobalLimitExec and converts it into a
TopK. The TopK's fetch was seeded from GlobalLimitExec::fetch(), which is the
limit's output row count and ignores skip. So the TopK kept only 4 rows, the
limit then skipped 3 of them, and the query returned a single row instead of 4.

The same seeding happens in two places in sort_pushdown.rs: when a root's direct
child is a GlobalLimitExec (assign_initial_requirements) and when the pushdown
descends through one (pushdown_sorts_helper). Both had the bug.

What changes are included in this PR?

• Add an input_fetch helper in sort_pushdown.rs that returns skip + fetch for
  GlobalLimitExec and plain fetch() for every other operator.
• Use it at both sites where the pushed-down fetch is derived from the plan node, so
  the TopK below a GlobalLimitExec retains enough rows for the limit to skip and
  still return fetch rows.

What is the testing strategy for this PR?

• limit.slt: new EXPLAIN + result test for LIMIT 4 OFFSET 3 under ORDER BY,
  showing TopK(fetch=7) below GlobalLimitExec: skip=3, fetch=4 and the correct
  4 rows.
• ensure_requirements.rs: two unit tests, one per code path
  (test_sort_pushed_below_limit_with_skip_keeps_skip_rows and
  test_parent_ordering_over_limit_with_skip_keeps_skip_rows), asserting the
  pushed sort has fetch=15 for skip=5, fetch=10.

Are there any user-facing changes?

Queries with a sort above LIMIT ... OFFSET now return the correct number of rows.
No API changes.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.62%. Comparing base (3dfa245) to head (0c73442).

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #24958      +/-   ##
==========================================
- Coverage   81.62%   81.62%   -0.01%     
==========================================
  Files        1124     1124              
  Lines      412462   412469       +7     
  Branches   412462   412469       +7     
==========================================
- Hits       336684   336678       -6     
- Misses      55965    55973       +8     
- Partials    19813    19818       +5     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ryux1]

The ordinary OFFSET case is covered well. I found one boundary condition in the new fetch calculation.

[ryux1]

GlobalLimitExec::new accepts arbitrary usize values, so this addition can overflow when skip + fetch > usize::MAX: debug builds panic, while optimized builds wrap and may turn the pushed sort into e.g. TopK(fetch=0), producing incorrect results. DataFusion's combine_limit uses saturating_add for the analogous limit composition. Could this use fetch.saturating_add(skip) as well, with a unit test covering skip = usize::MAX, fetch = 1 (or an equivalent overflow boundary)?