Offer Compare Plans across query sessions, not just within one (#447)

[erikdarlingdata]

Fixes #447.

The bug

QuerySessionControl.UpdateCompareButtonState() counted plans in the session's own sub-tabs:

foreach (var item in SubTabControl.Items)   // ← this session only
    ...
ComparePlansButton.IsEnabled = planCount >= 2;

Two queries in two separate sessions means one plan each, so the button stayed disabled in both — which is exactly the comparison it exists for.

Why the workaround worked

The plans were always reachable. MainWindow.CollectAllPlanTabs() spans sessions and labels them Query 1 > Plan, and the file-mode Compare button has always used it. Saving a plan and reopening it gave joshdbe a file tab, whose button looks at the window-wide collection. Only the session button was looking at the wrong one — in both its enablement and its own narrower picker.

The fix

The session button asks the window for both, and hands off to the window's picker rather than keeping a second one that can't see past its own session.

Refresh is one subscription to MainTabControl.Items collection-changed, not a call added at each of the 16 places that add or remove a tab. That matters more here than usual: a plan appearing in one session changes whether Compare is available in every other session, so a forgotten call site leaves a stale button somewhere the author never looked.

Kept a fallback to the session's own count for when there's no owning MainWindow — control not yet attached, or hosted elsewhere — so the button is never stale rather than throwing.

Tooltip updated; it said "Compare two plan tabs" and now means something wider.

Verifying without a SQL Server

Worth recording, because two sessions holding real plans otherwise need a live connection: open two .sqlplan files, then New Query. The session's Compare button is enabled and its picker lists both file plans. On dev it stays disabled — the session has no plans of its own and IsEnabled="False" is the XAML default.

No automated test

UI wiring, and the repo has no headless Avalonia harness — a test that would have caught this needs two constructed sessions and a window. A test on the arithmetic would be hollow: count >= 2 was never the broken part, the scope was.

314 tests unchanged, since nothing here touches Core.

🤖 Generated with Claude Code

[claude]

Reviewed. This is a clean, well-contained fix — no correctness issues found.

• The two refresh paths are complementary, not redundant: the 5 existing UpdateCompareButtonState() call sites (in-session plan add/remove) now forward to MainWindow.RefreshComparePlanAvailability(), while the new MainTabControl.Items.CollectionChanged subscription covers session/file-tab add-remove at the window level. Between the two, every mutation path that can change plan availability is covered.
• The TopLevel.GetTopLevel(this) is MainWindow fallback (CountOwnPlans() >= 2) is a sensible guard for detached/unattached hosting rather than a real gap.
• No SQL, no plan-XML parsing changes, no version-file or Blazor-linked-file surface touched by this diff, so those checklist items don't apply here.
• No automated test, but the PR body's reasoning holds — this is pure Avalonia UI wiring with no headless harness in the repo, and the fix is in the scope of the count, not the arithmetic, so a unit test on count >= 2 would be hollow anyway.

No blocking findings.