Stop re-reporting the same conflicts as needing manual resolution

[TheValiantOne]

What prompted this

A live 350-mod, game-build-4.04 install reported three conflicts as "needs manual resolution" on every run, with no way to make it stop:

File	Blocking mod	Enabled?	Merged output
game\vehicles\horse\states\exploration.ws	modFearlessRoach	no (Enabled=0)	none at all
game\gui\menus\mapMenu.ws	modFastTravelFromAnywhere	yes	4 days stale
game\r4Game.ws	modAlwaysFullExp	yes	4 days stale

The engine was right to decline all three — each has a source mod shipping a whole-file copy of a vanilla script taken from an older game build, so merging that side would delete vanilla code the game and the other contributing mod still call. That's the ValidateWholeFileMergeOutput invariant from #42 doing its job. The problem was that nothing said which mod to fix, and two separate gaps guaranteed the same files came back next run.

Changes

Tools/StaleBuildDetector.cs — runs the same vanilla-declaration comparison as a pre-flight, straight off the files with no merge involved, so the report names the stale mod and the remedy instead of pointing at a 2500-line file to hand-merge. Uses ScriptUnitExtractor's own ScopedName, so a pre-flight warning and a post-hoc violation name the same thing.

It is a diagnostic, never a gate — nothing here changes what does or doesn't merge, and the message deliberately stops short of predicting failure, because the check runs before any merge and can't know: on the live install one mod is missing 1 of 224 declarations and its conflict auto-solves every time, while another missing 13 reliably trips the invariant.

Inventory/MergeInventoryHygiene.cs + HasResolvedConflict — a record whose merged output file is gone was self-certifying: every hash it verifies belongs to a source mod, all present and unchanged when it's the output that was deleted. So it answered alreadyResolved: true forever, nothing ever re-merged it, and the game silently loaded exactly one of two conflicting mods. The GUI already refused to trust such a record (MainForm.RefreshMergeTree → ConfirmPruneMissingMergeFile, plus two siblings for a missing/disabled source mod) — all three rules were GUI-only. They now live in Core so the CLI, MCP tools and Vortex extension see them too.

They report rather than act, deliberately: the GUI's three prompts all pass no defaultResult, so HeadlessMergeNotifier would answer its generic YesNo → No to every one and prune nothing, silently — the same defect shape as the ConfirmOutputOverwrite finding already filed in docs/bugs/function-level-merge-gap-handling.md.

ModFileIndex disabled-mod skip — a scan is a filesystem glob, so a deployed-but-disabled mod counted as a full conflict participant and could keep a conflict permanently unmergeable. Only an explicit Enabled=0 excludes a mod; one absent from mods.settings counts as enabled (the game appends unknown folders on next launch), and a missing/unreadable mods.settings disables nobody — so this can never make a scan miss conflicts on a fresh install or a Linux host. MergeDisabledMods opts out, named for the opt-out so its absence from an older App.config yields the new behavior rather than silently keeping the old one. Skipped folders are always reported, never silent.

HeadlessMergeNotifier.RouteAllOutputToStandardError — found while testing the above. Only Error/Warning/Exclamation routed to stderr, so any default-icon message a scan emits went to stdout, which in mcp mode carries the JSON-RPC frame stream. Caught by a real scan_conflicts round-trip returning a payload the client couldn't parse, with the new disabled-mod notice spliced between two protocol frames. Pre-existing, not introduced here — BuildAsync's "Can't find any mods in the Mods directory." has the identical shape — so it's fixed at the root, set by both hosts' mcp verb. CLI mode is unaffected.

Verification

Run against the real install (dry-run/MCP only; the deployed tool and live inventory were never touched — a scratch copy was used):

• Before: 44 conflicts, 3 unmergeable, 1 inventory record with no output file.
• After: 43 conflicts (phantom gone), 43/43 resolved, 0 skipped.
• With WSM_MergeDisabledMods=true the phantom returns and the stale-build warning fires, naming modFearlessRoach and 13 of the 224 declarations it lacks — both features confirmed on one run.
• A static sweep over all 44 conflicts (136 mod-copy comparisons) found the stale-build signature in exactly the 3 the engine went on to decline.
• Separately, the two enabled stale mods' intended changes were ported onto current vanilla on that install (2 lines and 15 lines respectively — the rest of each mod file was just an out-of-date vanilla copy). Both then merged with zero warnings and zero function-level decisions, with no vanilla declaration lost and brace balance identical to vanilla. That's install remediation, not part of this PR.

dotnet build clean, 239 tests pass, dotnet format whitespace --verify-no-changes clean.

Test coverage

23 new tests. Both new test files stay inside the AppState.Settings-safety constraint in WitcherScriptMerger.Tests/CLAUDE.md — the pure two-string core of the detector is covered fully; the hygiene rules are covered only on the branches that return before resolving a real path (bundle exemption, null/empty guards, message formatting), since the flat-file ones reach Paths.ModsDirectory → AppState.Settings → Environment.Exit(1) in a test host. ExcludeDisabledModPaths was split out as a pure function for the same reason, matching the existing BuildIgnoredModNames precedent, and is covered fully — including that a null predicate or null path list excludes nothing, so an unreadable mods.settings can't make a scan silently report zero conflicts.

AI-assisted development

This PR was produced with Claude Code (Opus 5), per CONTRIBUTING.md. The diagnosis, the four fixes, the tests and the docs were all agent-written; every claim above was verified by actually running it against the real install and the real test suite, not inferred.

🤖 Generated with Claude Code

https://claude.ai/code/session_01N6y39x9F3SKcS4hhpw85Yi