Plan analysis: run the benefit scorer at every entry point and show each finding's benefit (#4546)

[erikdarlingdata]

Fixes #4546
Part of #4511

Why

BenefitScorer.Score existed but no product code called it: every entry point ran only PlanAnalyzer.Analyze. So no finding had a benefit value, and nothing the scorer computes was ever used.

What changes

• PlanAnalysisPipeline.Run(plan) (new, mirroring PerformanceStudio's PlanAnalysisPipeline) runs the analyzer and then the scorer, and returns early for a plan with no statements (which is also what a plan the parser refuses looks like). It replaces the direct PlanAnalyzer.Analyze(plan) call at all five entry points:
  • the Darling plan-advisory pass (PlanAdvisoryAggregator);
  • Darling drill-down (PgDrillDownCollector.Plans);
  • the MCP plan tools (McpPlanAnalysisFormatter);
  • Lite drill-down (Lite/Analysis/DrillDownCollector.Plans);
  • the plan viewer (PlanViewerControl.xaml.cs).
• The MCP plan tools: each finding carries max_benefit_percent (null when unscored), and findings are ordered by it, highest first, with unscored last. This is additive; the existing fields are unchanged.
• The plan viewer: as PerformanceStudio shows it, findings are ordered by benefit, and each header ends "— up to X% benefit" when it has one, in the plan-level and node-level warning lists. There's no new panel. The header and ordering logic live in PlanWarningDisplay, so they can be tested outside the UI.
• What this turns on: the scorer formulas already merged, i.e. the Serial Plan benefit (Serial Plan (rule 3) benefit uses the older two-branch formula #4528) and Bare Scan's operator-time benefit (Add rule 34: a bare scan with no predicate, with advice for a covering index or columnstore #4526), both in Plan analysis: Bare Scan rule and Serial Plan benefit formula (#4526, #4528) #4545. It also turns on any later scorer change as it merges (the wait findings, Wait stats never become findings: BenefitScorer computes a benefit for each wait but emits no warning #4516/The benefit for external and preemptive waits is far too low (MEMORY_ALLOCATION_EXT, PREEMPTIVE_*) #4517, are a separate PR).

Impact on stored advisories and alerts

This was checked before merge.

• The trace: plan findings reach Darling's analysis only as one PLAN_WARNING fact. FactScorer scores it presence-only (0.4), which is below the 0.75 Warning band and the 1.5 notification threshold. critical_count is read only by the advice headline text. Nothing reads MaxBenefitPercent outside the scorer, the MCP output and the viewer.
• Measured on 60 real showplans: the per-severity finding counts and finding types are identical with and without this change, because the scorer annotates existing findings and adds none itself. This change raises no new alert and moves no health band.
• Deep plans: the scorer's recursion was measured safe on a 1 MB thread at the parser's 1,000-level limit (about 15× margin; see Plan analysis: a deeply nested plan no longer crashes the process that parses it (#4512) #4551).

Test plan

• BenefitScorerWiringTests:
  • a census pin: no product file outside PlanAnalysisPipeline calls PlanAnalyzer.Analyze( directly;
  • through McpPlanAnalysisFormatter, a Serial Plan finding carries a non-null max_benefit_percent. Runtime RED on dev: KeyNotFoundException on max_benefit_percent, since dev's JSON has no such key;
  • findings are ordered by benefit, with null last;
  • an empty plan passes through untouched (Run_EmptyPlan_DoesNotThrow_AndLeavesPlanUnchanged).
• PlanViewerBenefitDisplayTests: the header with a benefit (⚠ Serial Plan — up to 67.5% benefit, plus [SQL Server] for engine warnings), the header without one, and the ordering 80, 20, null. These are compile-only RED on dev, because PlanWarningDisplay is new.
• Mutation: removing the Score call from PlanAnalysisPipeline.Run fails the MCP benefit fact.
• Run: Total: 239, Failed: 0, Skipped: 2 (the live-Postgres plan-tool class runs in CI). Lite.Tests and PerformanceMonitor.Ui build.

Also in this PR (test-only): PgWaitSamplerLiveTests.OneCycleAgainstAStockTarget_… now reads query_id and picks its own lock row (the one with the most samples) instead of asserting there is exactly one (Lock, relation) row. The sampler polls every session on the test server, so a concurrent test class's own relation-lock wait can add a second row; this PR's new test classes shifted the CI shard layout enough to expose it.

CHANGELOG

SECTION: Fixed
ENTRY: - Plan analysis now scores each finding's benefit, and the plan viewer and MCP plan tools show it ([#4552]) - The benefit scorer was never run, so no finding had a benefit value. Findings are now ordered by their estimated benefit. The viewer's headers read "— up to X% benefit", and the MCP plan tools report max_benefit_percent. This turns on the Serial Plan and Bare Scan benefit estimates.
REF: [#4552]: #4552