Plan viewer: a finding's header links to the operator it came from (#4534)

[erikdarlingdata]

Refs #4534
Part of #4511

Why

A plan-level or per-operator warning knows which operator it came from (PlanWarning.OriginNodeIds, landed in #4552/#4556), but the viewer's warning headers didn't expose it. A reader had to already know which operator to look at.

What changes

• PerformanceMonitor.PlanAnalysis/PlanWarningDisplay.cs: new OriginNavigationText(IReadOnlyList<int> originNodeIds) returns (Suffix, Tooltip)? — null when the list is empty (no affordance), otherwise a " →" suffix and a tooltip naming the operator ("Go to operator (Node 7)"), or for several origins, the first plus the rest ("Go to Node 7 — also from Node 9, Node 12").
• PerformanceMonitor.Ui/PlanViewerControl.Rendering.cs: new AttachOriginNavigation(TextBlock header, string headerText, List<int> originNodeIds) appends the suffix, sets a hand cursor and a transparent background (so the whole line hit-tests, not just the glyphs), attaches the tooltip, and wires MouseLeftButtonDown to navigate to the first origin node.
• PerformanceMonitor.Ui/PlanViewerControl.Properties.cs: both the plan-level and the per-operator warning header sites now call AttachOriginNavigation.
• PerformanceMonitor.Ui/PlanViewerControl.Interaction.cs: new TryNavigateToNode(int nodeId) finds the rendered Border tagged with that NodeId among PlanCanvas.Children, selects it, and scrolls it into view (new ScrollNodeIntoView, ported from the same navigation feature, using WPF's ScrollViewer offset/extent/viewport members). Returns false when no operator with that id is rendered, so a stale or wrong origin doesn't scroll to something arbitrary.

This mirrors PerformanceStudio's AttachOriginNavigation / TryNavigateToNode (Avalonia Cursor/ToolTip.SetTip/PointerPressed), translated to WPF's Cursors.Hand/ToolTipService/MouseLeftButtonDown.

Both the Darling viewer and Lite host the same shared PerformanceMonitor.Ui.PlanViewerControl (Darling/PerformanceMonitor.Darling.Viewer/MainWindow.PlanViewer.cs, ProcedureHistoryWindow.xaml.cs), so they both get this navigation for free — no separate change needed there.

Test plan

New class Darling.Tests.PlanViewerOriginNavigationTests:

• no IDs → OriginNavigationText returns null;
• one ID → suffix " →", tooltip "Go to operator (Node 7)";
• three IDs → tooltip "Go to Node 7 — also from Node 9, Node 12".

The WPF wiring (AttachOriginNavigation, TryNavigateToNode, ScrollNodeIntoView) can't run on macOS. Traced by hand: TryNavigateToNode(nodeId) walks PlanCanvas.Children, each of which is a Border whose Tag is set to its PlanNode in CreateNodeVisual (PlanViewerControl.Rendering.cs, Tag = node) — the same tagging Node_Click/SelectNode already rely on for click-to-select. For a real, rendered NodeId this loop finds the matching border, calls the existing SelectNode (used by direct clicks too), and ScrollNodeIntoView, which multiplies the node's unscaled X/Y by _zoomLevel and clamps the offset to [0, Extent - Viewport]. For a NodeId not present (stale data) the loop falls through and returns false, and no click handler is invoked.

• RED: compile-only on dev (OriginNavigationText is new). Mutation: returning an affordance for an empty list fails the no-IDs fact.
• Run: the new class plus the viewer and plan-analysis classes: Total: 237, Failed: 0. PerformanceMonitor.Ui, Lite and Darling.Tests build with 0 warnings. The Darling viewer and Lite both use this shared PlanViewerControl, so both get the navigation.

CHANGELOG

SECTION: Added
ENTRY: - Plan viewer: a finding's header links to the operator it came from ([#4559]) - Plan-level and per-operator warnings that know which operator they came from now show a small arrow in their header; clicking it selects and scrolls to that operator.
REF: [#4559]: #4559