Detect mod drift and make re-dumping a guided, integrated flow

[ApocDev]

The app's reference data is a static dump of the game's prototypes, so when the game's mods change (a mod updated, enabled, disabled, or removed) the dump no longer matches the game and a re-dump is needed. Today this is largely invisible: data_fingerprint is a hash of enabled mod names only (dump.ts:236-243), so it misses in-place version updates entirely, and nothing guides the user through re-dumping.

Detect drift: compare the game's current mod set against what the last dump was taken from, using both names and versions (the mod list already carries version, dump.ts:220). Flag added, removed, enabled, disabled, and version-changed mods, and surface a clear "your saved data no longer matches the game, a data dump is needed" state rather than letting blocks quietly fall out of sync.

Re-read the mod set and re-check for drift whenever it might have changed, not just once. Triggers:

• On app start.
• When the active project changes. Each project carries its own dump baseline in its meta (Persist and display the project's mod list (names + versions) #28), so the comparison is per-project and must re-run against the newly active project's baseline.
• When the bridge to the in-game mod reconnects, which usually means Factorio just restarted, possibly with a different mod set.
• Periodically in the background (every couple of hours is fine).

Reading the mod set is cheap (the mod-list file plus versions from the mods directory), so checking often costs little. Whenever a check finds the current set no longer matches the active project's stored baseline (#28), surface the re-dump prompt.

Make the re-dump feel integrated rather than a black box: a clear trigger, progress reporting through the dump and import steps, and a summary of what changed when it finishes.

The dump is where migrations get applied. Run the rename capture and application (#26) as part of it, then report any blocks that could not be auto-resolved and still need attention (#1). So the flow is: detect drift here, prompt and guide the re-dump, apply migrations during it, and hand anything still broken to the graceful-degradation handling.

[ApocDev]

Done — pushed to main. Detection in 05de0bc (docs ed49919); the guided UX and follow-ups in 1dc564f, 6ae0717, f03c994, d81d86f, 8705e32.

modDriftFn compares the current mod set against the persisted baseline by name AND version, categorizing added/removed/enabled/disabled/version-changed; needsRedump is true only when the enabled set or versions changed. A guided modal pops on detection (re-checks on app start, project switch, bridge reconnect, and every couple of hours), lets you ignore or re-sync, and walks the dump as a step-by-step progress flow ending in a summary that links to the block change-report. Also detects a running Factorio (via flock on ~/.factorio/.lock) and refuses to dump with a clear message rather than failing on the engine lock.