Plan viewer: color edges by the actual/estimated row ratio (#4579)

[erikdarlingdata]

Fixes #4579. Part of #4511.

Why

erikdarlingdata/PerformanceStudio@70d28e6 colors an actual plan's edges (the
elbow connectors between operators) by how far the child operator's actual
row count diverged from its estimate — instead of one flat gray line for
every edge. A user glancing at an actual plan can now see where the
optimizer's row estimate was badly wrong without opening every operator's
tooltip. PerformanceMonitor's plan viewer previously drew every edge in the
same flat EdgeBrush, with no accuracy signal at all.

What changes

• New pure helper PerformanceMonitor.PlanAnalysis.PlanEdgeColour.ForChild(hasActualStats, actualRows, estimateRows, divergenceLimit), returning one of 7 PlanEdgeColourKey values. Matches PerformanceStudio's GetLinkColorBrush exactly:
  • Estimated plans (no actual stats) always return Neutral (the plain default color).
  • accuracyRatio = actualRows / estimateRows (zero estimate + zero actual = 1.0; zero estimate + nonzero actual = double.MaxValue).
  • Inside [1/limit, limit], Neutral.
  • Outside it, three tiers each way at limit, limit×10, limit×100 — orange/red for more actual rows than estimated (underestimated), blue for fewer (overestimated).
  • divergenceLimit is floored at 2.0 inside the helper, matching PerformanceStudio's clamp.
• PlanViewerControl (the shared WPF control both hosts render) now calls this helper per edge instead of always using EdgeBrush, with the 6 non-neutral brushes at PerformanceStudio's exact hex values.
• New AccuracyRatioDivergenceLimit property on PlanViewerControl (default 10, PerformanceStudio's default), set by the caller before rendering.
• The setting itself: added AccuracyRatioDivergenceLimit to both hosts' persisted settings —
  • Lite: App.AccuracyRatioDivergenceLimit (new static property, default 10), read from settings.json's new accuracy_ratio_divergence_limit key (documented in settings.sample.json), applied at every PlanViewerControl construction site (ServerTab.Plans.cs, PlanViewerWindow.xaml.cs).
  • Darling Viewer: ViewerAppSettings.AccuracyRatioDivergenceLimit (persisted, normalized/floored on load) plus a new runtime static ViewerExportSettings.AccuracyRatioDivergenceLimit (the same "seed once, re-apply on Settings-window close" pattern the CSV separator already uses), applied at both PlanViewerControl construction sites (ViewerActualPlanFlow.cs, ViewerServerTab.Plans.cs).

Not ported

• No Settings-window control, as in PerformanceStudio: PerformanceStudio keeps AccuracyRatioDivergenceLimit in its settings file (default 10), and its Settings window only carries the value through Reset All; it has no control for it. PerformanceMonitor matches this. The limit lives in the Darling Viewer's viewer-settings.json and Lite's settings.json, with the same default, and there's no Settings-window control.

Test plan

New Darling/Darling.Tests/Viewer4579Tests.cs pins PlanEdgeColour.ForChild directly (a new pure type, no WPF dependency, runs on macOS): estimated-plan neutrality, exact-match neutrality, the zero-estimate edge cases, every tier boundary on both the underestimate and overestimate sides (just inside, at, just above/below each of limit, limit×10, limit×100), the divergence-limit floor, and the two public constants.

• Build (all green, 0 warnings): PerformanceMonitor.PlanAnalysis, PerformanceMonitor.Ui, Lite/PerformanceMonitorLite.csproj, Lite.Tests, Darling/PerformanceMonitor.Darling.Viewer, Darling/Darling.Tests — all built Release with -p:EnableWindowsTargeting=true, 0 Warning(s) / 0 Error(s) on every one.
• RED on dev: copied the new test file into a git worktree at origin/dev (130bc6a) and rebuilt Darling.Tests there — compile-only RED (PlanEdgeColour/PlanEdgeColourKey don't exist on dev, CS0103 on every reference).
• GREEN on this branch, in-process on macOS (Darling.Tests.dll with the WPF framework entry stripped from its runtimeconfig): -class Darling.Tests.Viewer4579Tests → Total: 20, Errors: 0, Failed: 0.
• Full mandated class set (Viewer4579Tests + every PlanSync*/Viewer* class + the fixed list of ActualPlan*/parser/MCP/doc-comment classes): Total: 1045, Errors: 0, Failed: 41, Skipped: 5. All 41 failures are in ViewerConfigDiagnosticsTests, ViewerDrillDownTests, ViewerHistoryWindowTests, ViewerServerTabTimeRangeTests, ViewerCalendarRetentionPortTests, ViewerSidebarDotRendersTheCardStatusTests, and ViewerTrendRoutingPortTests — none of them touch PlanViewerControl, PlanEdgeColour, or any file this PR changes (config-path anchoring, drill-down sorting/overlay, calendar retention, sidebar status dot, trend routing). I ran out of budget to prove these are pre-existing on dev with a second full run in a separate worktree (my one attempt hit an xunit CLI option-parsing error from too many -class arguments concatenated across two shell variables, not a test failure) — a follow-up should confirm these are dev-green-vs-branch-green identical before merge; I did not touch any of those seven files.
• Lite.Tests classes touched: none (no Lite-specific test file added or edited); the settings/App.xaml.cs changes there are covered indirectly by the build-only gate since Lite.Tests cannot run on macOS.

CHANGELOG

SECTION: Changed
ENTRY: - The plan viewer colours actual-plan edges by how far actual rows diverged from the estimate ([#4586]) - As in PerformanceStudio, an edge turns orange to red when the operator returned far more rows than estimated and blue when it returned far fewer, in three tiers each way, beyond a divergence limit that defaults to 10 and can be set in the settings file of Lite and the Darling Viewer. Estimated plans keep the plain edge colour.
REF: [#4586]: #4586

Refs

PS reference: erikdarlingdata/PerformanceStudio@70d28e6