[SQL] Support for nested (pure) lambda expressions APPLY(a, a -> APPLY(b -> b + 1)) - #6723

Draft review, high-level only.

Nice work. The invariants block on DBSPClosureExpression is the kind of documentation this codebase should have more of — it makes the rest of the diff auditable rather than "trust me". Two design-level thoughts worth chewing on before this leaves draft:

1. deepCopy() semantics are a footgun. The docstring correctly notes that copies share DBSPParameter objects because ParameterFieldUse keys results by them, and that callers who insert a copy into a tree containing the original must remember to freshen. In this PR you added exactly that freshen step in BetaReduction (for needsDeepCopy) and ensureTree (for duplicated subtrees). That's two use sites already. Every future caller of deepCopy() that keeps both trees will hit the same invariant, silently produce a malformed IR, and only crash in CanonicalForm — which is exactly what testEnsureTreeWithLambda documents. Worth considering:

• Split into deepCopyReplacing() (shares params — used when the copy replaces the original) vs deepCopyEmbedding() / deepCopyFresh() (freshens nested closures — used when both copies coexist), or
• Have deepCopy() freshen by default and add an explicit deepCopyForReplacement() for the ParameterFieldUse case (which is the rarer, more specialised path).

Either way, encode the invariant in the type / API name rather than in a comment.

2. Per-closure CSE map — correctness is clear, but re-check the "outermost gets everything left over" rule. In ExpressionsCSE.postorder(DBSPClosureExpression) you decide insert = outer || assign.owner == node. That's right for lambdas whose bodies don't reference outer variables (the "pure" case documented in the new invariant). But the invariant explicitly carves out post-lowering flatmaps that DO capture. In that case an assignment owner may be a nested-and-capturing closure and the outer closure is still marked outer. Is there a test after LowerCircuitVisitor that exercises this path? testLambdaCse and testNestedLambdaStreaming are pre-lowering. If the post-lowering DAG happens to work today it's by accident, and the "purity" invariant on DBSPClosureExpression says as much — but the invariant only warns readers, it doesn't guard ExpressionsCSE itself. Worth an explicit Utilities.enforce(closure.isPure()) or equivalent in the CSE entry point, or a targeted test after lowering.

Smaller stuff:

• MonotoneTransferFunctions.preorder(DBSPClosureExpression) now treats a nested closure as opaque non-monotone. Good, but the comment should say why the analysis is safe (the operator function's monotonicity does not depend on the lambda body's monotonicity because…) rather than just what it does. Future maintainers will otherwise wonder if they can improve precision here.
• RewriteNow correctly upgrades the internal-error assertion into a CompilationError. Good user-facing message, and the position range from closure.getNode() should give a decent squiggle.
• queryFailingInCompilation("SELECT transform(array[array[1]], a -> transform(a, a -> a + 1))", "Duplicate lambda parameter 'a'") — is that shadowing prohibition principled, or a workaround for the ResolveReferences implementation? SQL scoping is usually happy with inner-lambda shadowing (see e.g. Snowflake's HOFs). Not a blocker, but worth a sentence in the release notes.

Leaving as COMMENT since it's a draft. I'll do a proper line-by-line pass once you flip it to ready.

All three concerns from my draft review are addressed:

1. deepCopy semantics: documented in the DBSPClosureExpression invariant docstring + FreshenParameters helper freshens nested closure params wherever needed (ensureTree, BetaReduction). Not the API split I floated, but the approach is coherent and the helper makes it hard to forget.
2. Per-closure CSE: cseVariables keyed by DBSPClosureExpression + enclosingClosure() scoping + assign.owner == node insertion guard. Correct for move-capture Rust closures.
3. MonotoneTransferFunctions: comment now explains why opaque non-monotone is safe ("variables are not tracked by this analysis").

Tests cover the important cases: context cloning (testLetEquivalenceContextUnchanged), parameter freshening on DAG→tree (testEnsureTreeWithLambda), per-closure CSE (testLambdaCse), monotone acceptance (testNestedLambdaStreaming), duplication (testLambdaDuplication), and error paths (duplicate params, NOW() in lambda, enclosing-scope references).

LGTM.