A correlated subquery inside a derived table's body is rejected as LATERAL

[fupelaqu]

Introduced by story 22.3a (merged today, PR #341 / commit a6952974); present in 0.24.0-SNAPSHOT, not released.

Symptom

SELECT d.id
FROM (SELECT o.id FROM orders o
      WHERE EXISTS (SELECT 1 FROM returns r WHERE r.oid = o.id)) d

is rejected by Parser.apply:

Left(ParserError(LATERAL is not supported: a derived table cannot reference an outer alias.
'o.id' inside derived table 'd' reads the enclosing FROM (SQL-92 §7.6). Move the condition to the
outer WHERE, or write it as a correlated WHERE subquery.))

o is declared by d's OWN body, not by the enclosing FROM. This is an ordinary correlated
subquery living entirely inside the derived table — not LATERAL.

Measured on origin/main 36f0884e: SubqueryScope.correlationNames of the outer statement is
Set(d), and lateralOffenders still returns List((d, o.id)).

Cause

SubqueryScope.lateralOffenders reused correlatedReferences, whose walk accumulates the
enclosing names as it descends (deeper = outerScopes ++ innerNames). That accumulation is right
for the CORRELATION question — a body reading any enclosing scope must be reported at the outermost
statement, where routing is decided — and wrong for the LATERAL question, where the boundary is the
derived table itself and must not move. By the time the walk reached the WHERE subquery nested
inside d's body, d's own o had been folded into the "outer" set one level up.

Consequence

Story 22.3's own AC 11 requires exactly this shape to plan as a nested plan with the correlated
leg inside it. It never parses, so no planner row in softclient4es-arrow can assert it. Reported
by the 22.3b arrow implementer, who hit it end to end.

What must stay rejected

A reference that genuinely escapes the derived table — in JOIN position, in FROM position, nested
inside a WHERE-subquery body, two derived levels in, or naming the derived table's own enclosing
alias — is still LATERAL and must keep its current message.