fix: preserve global limit for multi-partition fetch

[discord9]

Which issue does this PR close?

• Closes LimitPushdown can mistake per-partition fetch for a global limit #23799.

Rationale for this change

An operator-level fetch applies independently to each output partition, so it cannot always replace a query-wide limit. For example, pushing LIMIT 5 into a two-partition scan as fetch=5 can return up to 10 rows.

The per-partition fetch is still useful as an early-stop hint, but the optimizer must distinguish that hint from a limit that still needs to be enforced. This distinction also affects OFFSET, existing fetches, partition ordering, and operators with multiple children.

What changes are included in this PR?

LimitPushdown now tracks both the limit values (skip and fetch) and whether a local or global limit is still pending:

Pending state	Meaning
Local	Each output partition still needs its own limit.
Global	One limit still needs to be applied to the combined output.
None	The limit is already enforced; a retained fetch is only an early-stop hint.

The rule handles the relevant cases as follows.

Partition scope

• A pending global limit over multiple output partitions is enforced only after the partitions are combined.
• CoalescePartitionsExec is used when no ordering must be preserved.
• SortPreservingMergeExec is used when the limit requires the input ordering to remain intact.
• A local limit at a single-output operator is promoted to global before descending, because that operator may hide multiple input partitions.

OFFSET and existing fetches

• A child may receive skip + fetch as an early-stop hint, but a fetch alone never implements OFFSET.
• An existing operator fetch satisfies a pending limit only when there is no OFFSET and existing_fetch <= required_fetch.
• A looser fetch is tightened through with_fetch when supported; otherwise an explicit limit remains.
• A tighter existing fetch is preserved rather than widened.
• A no-op GlobalLimitExec (skip=0, no fetch) is removed without creating a partition-combining boundary.

Unary and custom operators

supports_limit_pushdown means that a limit may be delegated through an operator; with_fetch separately means that the operator can apply a fetch to its own output.

• An unknown operator uses the conservative defaults: it blocks pushdown, and an explicit limit is kept above it unless its with_fetch implementation can enforce the output bound.
• A unary operator that declares supports_limit_pushdown may pass a pending limit to its single child.
• If an operator accepts with_fetch, it can enforce the bound on its own output. With OFFSET, an explicit GlobalLimitExec is still required above it.

Operators with multiple children

A pending limit is not copied independently to every child of an arbitrary multi-child operator, because their combined output could exceed the requested row count.

• The limit is first enforced on the multi-child operator's output, either through its with_fetch implementation or an explicit limit node.
• After that enforcement, pending is cleared and only a safe early-stop fetch is passed to the children.
• UnionExec is a narrow exception for local limits: each Union output partition comes from one child partition, so the same per-partition local limit can safely be delegated to its children.
• A global limit over Union is still enforced over the combined output before descending.

What is the testing strategy for this PR?

The physical_optimizer::limit_pushdown integration tests cover 42 plan shapes, including:

• fetch-capable and unfetchable multi-partition inputs;
• ordered and unordered global materialization;
• LIMIT, OFFSET + LIMIT, and OFFSET-only plans;
• tighter, looser, and immutable existing fetches;
• unary operators that hide multi-partition children;
• arbitrary multi-child operators, with and without with_fetch;
• safe child hints after output enforcement;
• local and global limits over Union;
• nested limits and no-op global limits.

Verified on the latest rebased branch with:

cargo fmt --all --check

cargo test -p datafusion --test core_integration \
  physical_optimizer::limit_pushdown::
# 42 passed; 0 failed

cargo test -p datafusion-physical-optimizer limit_pushdown
# 2 passed; 0 failed

cargo clippy -p datafusion -p datafusion-physical-optimizer \
  --all-targets --all-features -- -D warnings
# passed

git diff --check
# passed

Are there any user-facing changes?

Yes. Affected plans now preserve query-wide LIMIT/OFFSET semantics instead of returning too many rows or applying an offset more than once. There are no public API or configuration changes.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 94.01709% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.63%. Comparing base (27e81e9) to head (a403530).
⚠️ Report is 5 commits behind head on main.

Files with missing lines	Patch %	Lines
...atafusion/physical-optimizer/src/limit_pushdown.rs	94.01%	4 Missing and 3 partials ⚠️

Additional details and impacted files

@@           Coverage Diff            @@
##             main   #23800    +/-   ##
========================================
  Coverage   81.63%   81.63%            
========================================
  Files        1123     1123            
  Lines      409729   410016   +287     
  Branches   409729   410016   +287     
========================================
+ Hits       334496   334733   +237     
- Misses      55576    55600    +24     
- Partials    19657    19683    +26     

☔ 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.

[neilconway]

Thanks for your work on this, @discord9! This PR is overall very good: thorough explanation of the problem, very good test coverage, and well-written implementation. I spent a while working through it and talking to Claude and the basic approach makes sense to me and clears up a clear semantic shortcoming of the current representation.