Plan analysis: parsing and analysis stop when the caller cancels, and the async path enforces the size limit (#4512)

[erikdarlingdata]

Fixes #4512
Part of #4511

#4557 (#4514) is already merged; this branch contains it.

Why

A plan-analysis pass that keeps parsing and analyzing after the caller has already given up wastes work on a plan nobody is waiting for. The MCP plan tools, the Darling and Lite analysis passes, and the drill-down collectors all have a cancellation token in scope; the parser, the analyzer, the benefit scorer and the pipeline that chains them together did not check it, so a cancelled request or a shutting-down analysis pass ran the full parse/analyze/score sequence to completion regardless.

What changes

• ShowPlanParser.Parse and the new ParseAsync take a CancellationToken. A cancellation surfaces as OperationCanceledException, never as ParsedPlan.ParseError (callers treat a ParseError as "this plan is bad", not "the caller gave up"). ParseAsync runs the same dedicated 32 MB-stack thread parse as Parse (the thread completes the returned task), so a deeply nested plan can't overflow the caller's stack on either path, and both share one up-front size check with the same message. The production callers use the synchronous Parse.
• The dedicated parse thread also catches any other exception (for example an out-of-memory near the size limit) and reports it as a parse failure instead of ending the process. A cancellation reaches the caller as the original OperationCanceledException, with its stack.
• PlanAnalyzer.Analyze and BenefitScorer.Score check the token per statement and down their node-tree walks.
• PlanAnalysisPipeline.Run (and the new RunAsync) check the token before, between and after the analyze and score stages, so a cancellation stops the pipeline before the next stage instead of finishing.
• McpPlanAnalysisFormatter.BuildAnalysisResult takes and forwards the token.
• Every caller that has a token now passes it through: the Darling and Lite MCP plan tools (analyze_query_plan, analyze_procedure_plan, analyze_query_store_plan, analyze_plan_xml), PlanAdvisoryAggregator.ExtractCancellable/SummarizeCancellable (new names that carry the token; the token-free Extract/Summarize keep their signatures), and both drill-down collectors (Darling/PerformanceMonitor.Darling.Analysis/PgDrillDownCollector.Plans.cs, Lite/Analysis/DrillDownCollector.Plans.cs). Each catch clause that used to swallow every exception is narrowed so a cancellation propagates instead of being reported as a parse or analysis failure (the drill-downs already had abandon-classifier filters — AnalysisShutdown.IsExpectedAbandon / AnalysisAbandon.IsExpected — which recognize a cancelled token's OperationCanceledException as an expected abandonment, not a fault).
• Not ported (no equivalent in this codebase): PlanSession, PlanOperations, InMemoryPlanCatalog, PlanXmlPreflight, the CLI/text formatters, and the shared resource-budget machinery.

Test plan

New Darling/Darling.Tests/PlanSync4512CancellationTests.cs, 8 pins:

• PlanSync4512AsyncParseTests: a 500-level plan through ParseAsync, awaited from a real 1 MB thread, returns normally (501 operators, no ParseError). On the previous code this crashes the process with a stack overflow, so its RED was shown locally in a separate process (exit 134, "Stack overflow."; exit 0 with the fix; 134 again with ParseAsync walking the tree itself). The async size refusal gives the same message as the sync path.
• a pre-cancelled token on both Parse and ParseAsync throws OperationCanceledException, not a ParseError.
• cancellation from inside the walk, deterministically: an internal per-statement hook (an AsyncLocal, so parallel tests can't interfere) cancels after statement 3 of 50; the test asserts the OperationCanceledException and that parsing stopped there. Removing the in-walk checks turns it RED (an assertion, no crash).
• PlanAnalysisPipeline.Run with a cancelled token throws before either the analyzer or the scorer adds anything (ParsedPlan.AllWarnings stays empty).
• ParseAsync on XML over the size limit sets ParseError with no exception and no cancellation — a size refusal is a parse failure, not a cancellation.
• the no-token overloads (Parse(xml), Run(plan)) give the same result as the token overloads called with CancellationToken.None, on a normal plan.
• a classifier pin (AbandonClassifier_TreatsCancelledParseAsExpected): AnalysisShutdown.IsExpectedAbandon returns true for an OperationCanceledException against a cancelled token — the half of the drill-down's catch-filter guard both PgDrillDownCollector.Plans.cs and Lite/Analysis/DrillDownCollector.Plans.cs share, which is why a cancellation from ShowPlanParser.Parse inside a drill-down propagates instead of being caught and reported as a bad plan.

Mutation: removed Parse's dedicated-thread catch that captures an OperationCanceledException and rethrows it on the caller's thread. On the pre-fix behavior this is fatal to the whole test process — the parser's own comment says an unhandled exception on that non-pool thread has nowhere to go — so the RED here is the pin-runner process itself terminating instead of printing a [FAIL] line, not a failing assertion. Reverted; the 8 pins are green again after rebuilding.

Build (Release, -p:EnableWindowsTargeting=true): Darling.Tests, Lite, Lite.Tests, PerformanceMonitor.Ui, Darling/PerformanceMonitor.Darling.Service and Dashboard.Tests — all 0 Warning(s), 0 Error(s). grep -E "warning (CA|CS|IDE)[0-9]+" across all four build logs: empty.

Run (in-process on macOS, Microsoft.WindowsDesktop.App stripped from Darling.Tests.runtimeconfig.json), the plan-analysis classes plus the new ones:

Total: 274, Errors: 0, Failed: 0, Skipped: 2, Not Run: 0 (after the review fixes; 362 on the first cut)

The 2 skipped are the live-Postgres classes (DarlingMcpPlanToolsLivePostgresTests, and the live fixture inside DarlingAnalysisPipelineTests) — they need a live store and run in CI.

Lite.Tests builds (0/0) but cannot run here (net10.0-windows, discovery dies on WindowsBase on macOS); CI decides it.

CHANGELOG

SECTION: Fixed
ENTRY: - Plan analysis stops when its caller cancels ([#4560]) - The MCP plan tools stop parsing and analysing a plan when the client cancels the request, and the Darling and Lite analysis passes stop on shutdown instead of finishing a large plan first.
REF: [#4560]: #4560