Stop the test harness from mutating real machine state

[erikdarlingdata]

What does this PR do?

Fixes the confirmed-live finding from the 2026-09-02 adversarial review: the #451 headless harness boots the real App, so every local dotnet test run fired real startup side effects inside the test host — it rewrote HKCU's .sqlplan association and DefaultIcon to the test executable, loaded/cleared/polluted the developer's real appsettings.json (fixture paths evicted real Recent Plans entries; the saved open-tab list was destroyed), started ~36 never-stopped named-pipe servers and GitHub update checks per run, and could bind the real MCP port.

One seam, not scattered env sniffs: AppRuntimeMode.IsTestHost, set by a [ModuleInitializer] in the test assembly before the first App boot (and before any test can touch settings, harness user or not). Under it: the association write, pipe server, startup update check, and MCP start are skipped (each with a comment naming the side effect it prevents), the clipboard guard latches once per process instead of stacking per test dispatch, and AppSettingsService redirects to a per-run temp directory. Nothing in the product sets the gate or calls the redirect — with it unset, every path keeps its static-constructor default byte for byte.

The pinning test asserts flags set by the launch methods themselves, not by the gate, so a future launch path that sidesteps the gate still fails the test.

How was this tested?

Full suite twice in a row (per-run isolation proof): identical green results, each run creating its own temp settings dir while the real appsettings.json mtime never moved and the registry was not rewritten. At dev tip: 425 tests, 424 passed, 1 platform skip, 0 failed. No existing test needed its assumptions changed — the suite was already clean-profile shaped.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PvAv72Pwb8czsjDWsCCk7n

[claude]

Reviewed. This is a clean, well-scoped fix — no plan-XML parsing or T-SQL generation is touched, so the untrusted-input and SQL-injection concerns don't apply here.

Checked specifically:

• Gate placement: AppRuntimeMode.IsTestHost correctly gates FileAssociationService.RegisterForCurrentExecutable, StartPipeServer, CheckForUpdatesOnStartupAsync, and StartMcpServer at exactly their prior unconditional call sites in App.axaml.cs/MainWindow.axaml.cs — order of operations in the constructor is otherwise unchanged.
• Ordering guarantee: [ModuleInitializer] on HeadlessUi.EnterTestHostMode is the right tool — it's guaranteed to run before any other static member access in the assembly, including the Session Lazy<T> that boots the real App, and before any test touches AppSettingsService directly (which the harness setup approach couldn't guarantee). Only one test assembly exists (PlanViewer.Core.Tests), so the module-initializer scope is sufficient — there's no second test project that would boot the real App without this seam applying.
• Settings redirection: AppSettingsService's SettingsDir/SettingsPath/OldFormatSettingsPath going from readonly to mutable, gated by a single internal redirect method, is a reasonable test-seam trade-off. Verified Load/Save/MigrateFormatSettings all route through the same mutable fields — no hardcoded path bypasses the redirect.
• Test pinning design: PipeServerStarted/StartupUpdateCheckStarted/McpServerStartAttempted are set by the launch methods themselves rather than by the gate, so TestHostIsolationTests actually fails if a future change starts one of these through a new path instead of just re-asserting the gate's own value.
• TextBoxClipboardGuard latch: applies unconditionally (not gated by IsTestHost), which is correct — it's a general idempotency fix for repeated App boots in the same process, harmless in production where Register() already only runs once.

No warnings introduced, no version-bump or Blazor-linked-file conventions apply (no Directory.Build.props/PlanViewer.Ssms/PlanViewer.Core files touched). Nothing further to flag.