Carry the parse depth through proc and UDF descent

[erikdarlingdata]

What does this PR do?

Fixes the highest-severity finding from the 2026-09-02 adversarial review of the Aug 12 - Sep 2 range.

#456's StoredProc/UDF descents called ParseStatementAndChildren without the depth argument, so recursion depth silently reset to zero at every procedure boundary and the MaxParseDepth guard could never fire across procedure nesting. A crafted .sqlplan alternating StmtSimple > StoredProc > Statements a few thousand levels deep (~60 bytes per level) killed the process with an uncatchable StackOverflowException, from any plan-open route. Shipped in v1.22.0+.

• Depth is now threaded through ParseStatement (where the descent sites live) and both descents pass depth + 1.
• The synchronous Parse path (app UI, web viewer, analysis pipeline) gains the same 16MB ceiling ParseAsync always had, via the shared const.
• Three new tests: a generated ~1,100-level depth bomb on a dedicated big-stack thread (fails cleanly in both directions — verified red against the unfixed parser), a 50-level positive test walking every parsed level, and a sync size-cap pin.

How was this tested?

Full suite at dev tip + fix: 408 tests, 407 passed, 1 platform skip, 0 failed, on Windows. Red-green verified against the unfixed parser. Web and App projects build clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PvAv72Pwb8czsjDWsCCk7n

[claude]

Reviewed. The depth-threading fix is correct: ParseStatementAndChildren now passes depth (same level) into ParseStatement, which forwards depth + 1 into both the UDF and StoredProc descents — this is the exact reset #456 introduced, and it's closed on both paths. The StmtCond branches already incremented correctly and are untouched. The sync Parse size cap correctly mirrors ParseAsync's existing MaxCharactersInDocument (char-count semantics, same constant), and sits inside the existing try/catch so it degrades to ParseError like every other failure mode here — good, no untrusted-input path throws uncaught.

Tests are well-targeted: the depth-bomb test isolates the parse on a dedicated 8MB-stack thread so it fails on the assertion rather than the test host if the guard regresses, and the 50-level positive test walks the actual StoredProcPlan chain rather than just checking for the absence of an error. The oversized-input test uses well-formed XML so it can't pass by accident on a syntax error.

One thing worth a sentence of awareness rather than a fix: ParseRelOp's operator-tree depth counter (RelOp.cs) is independent of this statement-depth counter and resets to 0 at each statement boundary (both call sites at lines 373/423 omit the depth argument). A pathological plan could in principle stack ~1000 StoredProc levels on top of a ~1000-deep operator tree in the deepest statement, compounding to ~2000 real frames on one call stack instead of ~1000. That's pre-existing (not introduced here) and the two guards were clearly designed independently, so not blocking — just flagging in case a future hardening pass wants to thread a combined budget through both.

No version bump needed here (this PR targets dev, and check-version-bump.yml only gates dev → main). No T-SQL, no PlanViewer.Web linked-file surface touched. Looks good to merge.