fix: keep the OFFSET of a correlated EXISTS subquery

[fornwall]

Which issue does this PR close?

Closes #25283.

Rationale for this change

A correlated EXISTS subquery with an OFFSET returns wrong results, because the OFFSET is dropped when the subquery is rewritten into a semi join:

CREATE TABLE t1(k INT) AS VALUES (1), (2), (3);
CREATE TABLE t2(v INT) AS VALUES (1), (1), (3);

SELECT k FROM t1 WHERE EXISTS (SELECT * FROM t2 WHERE t2.v = t1.k OFFSET 1);

Only k = 1 has two matching rows, so the expected result is a single row with 1 (as SQLite returns). DataFusion returns 1 and 3. NOT EXISTS is wrong the same way.

PullUpCorrelatedExpr removes the LIMIT above the correlated filter of an EXISTS subquery, since LIMIT n with n > 0 cannot change whether any row exists. But the same node carries the OFFSET, which can turn a non-empty subquery into an empty one.

The decision to remove a Limit was also keyed on whether any correlated predicate had been collected so far, not on whether one sat below this Limit. In a join inside the EXISTS the correlated side is visited first, so a LIMIT on an uncorrelated sibling branch was removed too, changing the result:

SELECT t1_id FROM t1 WHERE EXISTS (
  SELECT 1 FROM (SELECT * FROM t2 WHERE t2_id = t1_id) a
  JOIN (SELECT * FROM t3 ORDER BY t3_id LIMIT 1) b ON a.t2_int = b.t3_int)

With the subquery.slt fixtures this returned 11, 22, 44 instead of 11, 44.

What changes are included in this PR?

PullUpCorrelatedExpr now decides per Limit, in f_down, whether it sits above correlated expressions, using the outer references of its own subtree (as it already did for IN subqueries), and rewrites the Limit right there.

For a correlated EXISTS, the Limit is only removed when it cannot change whether the subquery is empty: a zero offset with a literal fetch. A zero fetch still becomes an empty relation. Anything else (a positive or non-literal offset, or a non-literal fetch) marks the subquery as not pull-up-able, so it stays correlated and fails as unsupported instead of returning wrong rows.

A Limit with no correlated expressions below it is left alone.

What is the testing strategy for this PR?

New sqllogictest cases in subquery.slt:

• LIMIT 1 OFFSET 0 is still decorrelated.
• OFFSET 1 keeps the subquery correlated, and running the query fails with a not-implemented error. The explain case fails without the fix. The same for NOT EXISTS, and for EXISTS in a disjunction.
• LIMIT 0 OFFSET 1 still becomes an empty relation.
• A non-literal LIMIT keeps the subquery correlated.
• A LIMIT or OFFSET on an uncorrelated branch of a join inside the EXISTS is kept and the query returns the correct rows. Both fail without the per-Limit decision.

Are there any user-facing changes?

• A correlated EXISTS / NOT EXISTS subquery with a positive OFFSET, or with a non-literal LIMIT, now fails with a not-implemented error instead of returning wrong results (previously the LIMIT / OFFSET was silently dropped). I can file an issue and take a stab at supporting these in a follow-up once this is merged.
• A LIMIT or OFFSET on an uncorrelated branch inside a correlated EXISTS subquery is no longer dropped, so such queries now return correct results.

Disclaimer: Created with fable 5.1 in claude code. I have reviewed the code.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 83.87097% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.92%. Comparing base (a0631ed) to head (c666d06).

Files with missing lines	Patch %	Lines
datafusion/optimizer/src/decorrelate.rs	83.87%	2 Missing and 3 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #25284      +/-   ##
==========================================
- Coverage   81.92%   81.92%   -0.01%     
==========================================
  Files        1135     1135              
  Lines      427573   427583      +10     
  Branches   427573   427583      +10     
==========================================
- Hits       350279   350278       -1     
- Misses      56367    56374       +7     
- Partials    20927    20931       +4     

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