Route LoadOrderValidator's prompt through Program.Notifier

[TheValiantOne]

Summary

• LoadOrderValidator.PromptToPrioritizeMergedMod called MessageBox.Show directly instead of Program.Notifier.ShowMessage, unlike every other domain call site in the codebase. Its sole caller (ValidateAndFix) is currently only ever invoked from Forms/MainForm.cs, so this was harmless today, but it's a landmine for any future headless (CLI/MCP) load-order validation path — an unmediated WinForms MessageBox.Show with no message pump watching it. This change routes it through Program.Notifier.ShowMessage, matching the pattern used everywhere else (e.g. LoadOrder/CustomLoadOrder.cs's ShowWarningForMalformedFile).
• IMergeNotifier.ShowMessage gained a trailing optional MessageBoxDefaultButton defaultButton = MessageBoxDefaultButton.Button1 parameter. The original call passed MessageBoxDefaultButton.Button2 (defaulting focus to "No"); dropping it silently would have flipped the Enter-key default from "leave my load order alone" to "rewrite mods.settings" — not behavior-preserving. MainForm.ShowMessage forwards it to the 6-arg MessageBox.Show overload; HeadlessMergeNotifier ignores it (no dialog is ever shown headlessly — see below). Only two types implement IMergeNotifier (MainForm, HeadlessMergeNotifier), both updated; the new parameter is a trailing optional so no existing call site needed changes.
• The MessageBoxManager.Register()/Cancel = "Ne&ver"/Unregister() wrapping (a SetWindowsHookEx-based hack to relabel the Cancel button "Never") is removed, not preserved, and is a genuine, disclosed regression — not a no-op cleanup. The old hook worked because the old MessageBox.Show call ran directly on the same background thread Register() hooked (no owner window, no marshalling). Program.Notifier.ShowMessage → MainForm.ShowMessage marshals the actual MessageBox.Show call onto the UI thread via Invoke whenever called off-thread — which this call always is, since LoadOrderValidator.ValidateAndFix runs inside MainForm's Task.Run. The hook (registered on the calling thread) can no longer see the dialog's window messages once routed through the notifier. Preserving it would require adding custom button-text support to IMergeNotifier, which is out of scope for this fix. User-visible effect: the Cancel button now reads "Cancel" instead of "Never" — clicking it still permanently disables this validation check (unchanged DialogResult semantics), just without a label saying so.
• ValidateAndFix's Cancel branch is now additionally guarded on Program.Notifier.IsInteractive. HeadlessMergeNotifier's fixed non-destructive default for YesNoCancel is Cancel, which at this specific call site means "Never" → Settings.Set("ValidateCustomLoadOrder", false); Settings.Save(). Without the guard, a future headless caller reaching this code would silently persist a settings change to App.config — exactly the landmine this PR exists to defuse. With the guard, a headless run is a safe no-op instead.

Why

Closes a "safe only by accident" gap flagged for follow-on headless load-order validation work: LoadOrderValidator was the one remaining domain-layer file bypassing the IMergeNotifier abstraction that the rest of the codebase (CustomLoadOrder, FileMerger, AppSettings, Paths, the Tools/* wrappers) already routes through, which is what makes CLI/MCP mode possible for everything else.

Verified

• dotnet build WitcherScriptMerger.sln succeeds with no new warnings (same 7 pre-existing warnings as main: NU1510, and CA1823 unused-field warnings in unrelated files).
• dotnet format whitespace WitcherScriptMerger.sln --verify-no-changes passes (exit 0).
• No GUI automation harness is available in this environment, so this was verified by code inspection rather than an interactive run: confirmed the button set (YesNoCancel), icon (Exclamation), message text, and DialogResult handling in ValidateAndFix are byte-for-byte identical to the original MessageBox.Show call (the "Ne&ver" label change is the one disclosed exception, see above).
• Confirmed by reading Program.cs that Program.Notifier is reassigned from the default HeadlessMergeNotifier to MainForm immediately after construction, before Application.Run starts the message loop — and confirmed by tracing callers that PromptToPrioritizeMergedMod's only reachable path (MainForm_Shown → RefreshMergeInventory → LoadOrderValidator.ValidateAndFix) runs from the Shown event and later user-triggered handlers, never from MainForm's constructor. So this change can't introduce a window where the prompt silently goes to the headless notifier instead of showing a dialog to the interactive user.
• Grepped the codebase for remaining unmediated MessageBox.Show calls: the only ones left are in Forms/MainForm.cs and Forms/DependencyForm.cs, both GUI-layer code where a direct call is correct (no Program.Notifier indirection needed there).
• Ran the code-review skill against this branch. It surfaced 7 findings; addressed the 3 in scope (see commit "Address code-review findings..."): simplified enum literals back to unqualified for in-file consistency, strengthened the "Ne&ver" regression comment after review correctly identified it as a real behavior change rather than the inert cleanup an earlier, terser comment could have read as, and documented why HeadlessMergeNotifier accepts but ignores defaultButton. The other 4 findings are out of scope for this unit and are noted below for whoever picks up the relevant follow-on work.

Out of scope, flagged for other units

• HeadlessMergeNotifier.Write routes MessageBoxIcon.None messages to stdout, which risks corrupting the MCP JSON-RPC stream if reached during an MCP session (pre-existing behavior, not introduced here, but live in a file this PR touches) — belongs to MCP-hardening work.
• Forms/MainForm.cs's PromptToDeleteForChangedHash (an analogous "permanently disable a check" prompt for ValidateMergeSources) still uses the MessageBoxManager "Ne&ver" relabel and still works there (same-thread, no Program.Notifier involved) — after this PR, the app has one prompt that says "Never" and one that says "Cancel" for structurally similar choices. PromptToDeleteForChangedHash is GUI-layer code outside LoadOrderValidator.cs, so not touched here.

Heads-up for other in-flight units

This PR touches IMergeNotifier.cs, HeadlessMergeNotifier.cs, and MainForm.cs's ShowMessage — the interface a later unit is expected to refactor toward a UI-neutral return type. The added MessageBoxDefaultButton parameter is a trailing optional and can't break any existing caller, but whoever picks up that refactor will hit a textual merge conflict in these three files.

Disclosure

This PR was substantially produced with Claude Code (an AI coding agent), per this repo's AI-assisted-development policy in CONTRIBUTING.md. I've reviewed the diff and can explain any part of it if asked.