fix: prevent DISTINCT ORDER BY LIMIT from returning too few rows

[geoffreyclaude]

Which issue does this PR close?

• Closes SELECT DISTINCT ... ORDER BY ... LIMIT can return too few rows with multiple partitions #24927.

Rationale for this change

With multiple partitions, SELECT DISTINCT ... ORDER BY ... LIMIT can return fewer rows than requested even when enough distinct values exist.

DISTINCT runs in partial and final stages. Sort pushdown was moving the final TopK fetch (the sort's row limit) below the final aggregation, while duplicate partial results still existed:

SortPreservingMergeExec: fetch=3
  AggregateExec: final DISTINCT
    SortExec: TopK(fetch=3)       <-- limit is applied too early
      AggregateExec: partial DISTINCT

Duplicates could fill the limit and discard another value before the final DISTINCT had a chance to remove them.

The corrected plan keeps the limit above the final DISTINCT:

SortPreservingMergeExec: fetch=3  <-- limit is applied after DISTINCT
  AggregateExec: final DISTINCT
    SortExec                      <-- ordering only; no limit
      AggregateExec: partial DISTINCT

I bisected this regression to 450c861a8c (#14821), first released in 47.0.0. That refactor made the ordering-satisfied fast path forward fetch to the current plan's children. It correctly established that the current plan preserved the requested ordering, but preserving order does not mean that moving a limit is safe. The shortcut consequently bypassed the existing limit-pushdown and cardinality checks: the parent of that commit returns 0, 1, and 2, while the commit itself returns only 0 and 2.

What changes are included in this PR?

When a plan already satisfies the requested ordering, sort pushdown first tries to keep a pending fetch on that plan through the generic ExecutionPlan::with_fetch capability. It forwards the fetch to children only when the plan explicitly supports limit pushdown and produces exactly one output row for every input row.

If an already ordered plan can neither retain nor safely forward the fetch, the optimizer keeps the limit above it with a LocalLimitExec or GlobalLimitExec, adding a sort-preserving merge when a single output partition is required. This carries the limit without introducing a redundant sort and gives subsequent optimizer runs the same canonical plan shape.

What is the testing strategy for this PR?

An SQLLogicTest in limit.slt uses the exact two-partition query from #24927 and verifies that it returns 0, 1, and 2. Focused physical optimizer tests verify the stable limit-carrier plan across another optimizer pass and verify that fetch is still forwarded through a safe equal-cardinality plan.

Are there any user-facing changes?

Yes. Affected queries now return all requested distinct rows. There are no API or configuration changes.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 85.29412% with 10 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.58%. Comparing base (20d1c56) to head (b30d074).
⚠️ Report is 7 commits behind head on main.

Files with missing lines	Patch %	Lines
...sure_requirements/enforce_sorting/sort_pushdown.rs	85.29%	9 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #24932      +/-   ##
==========================================
- Coverage   81.64%   81.58%   -0.06%     
==========================================
  Files        1123     1123              
  Lines      410248   410965     +717     
  Branches   410248   410965     +717     
==========================================
+ Hits       334940   335300     +360     
- Misses      55617    55916     +299     
- Partials    19691    19749      +58     

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