Capture mod prototype renames and auto-apply them to saved blocks

[ApocDev]

When a mod renames a recipe, item, or fluid prototype, saved blocks that reference the old name should follow the rename automatically rather than appearing broken. A pure rename is just a string substitution across the stored references, so it can be applied without user intervention.

Source of renames: Factorio mods ship declarative migration files at migrations/*.json, mapping old prototype names to new ones per prototype type. These live inside the mod zips under ~/.factorio/mods, which the app backend already reads for the mod list (dump.ts:28-29, :220). The mod's own Lua runtime cannot read other mods' migration files, but the backend can read them straight from the zips, and the mod list already carries each mod's version. The .lua migration files are procedural save-state scripts, not prototype renames, and are out of scope.

Capture: on each data dump, read every enabled mod's migrations/*.json and keep a record of which migration files have already been applied (by mod plus file or version). A migration file that is newly present since the last dump is a new rename to apply. This is the "previous versus current" tracking: only migrations not already processed are acted on.

Apply: for each old-to-new rename, substitute the name everywhere a saved block references it. From BlockData (db/schema.ts:283-293): target, extraGoals, recipes, the keys of dispositions, machines, fuels, modules, and beacons, the fuel/module/beacon member names, and the block's iconName. Record each migration as processed once applied.

This runs as part of the dump flow (#27), so renames resolve before the user is asked to deal with anything. References that changed meaning or genuinely disappeared, rather than just being renamed, are not covered here and fall through to the graceful-degradation handling in #1.

[ApocDev]

Done — implemented in 7673aa8 (docs 3de91b3), pushed to main.

migrations.ts reads each enabled mod's migrations/*.json from its zip (via fflate) or unpacked folder and applies prototype renames across every block reference (target, extraGoals, recipes, the recipe-keyed machines/fuels/modules/beacons + member names, disposition keys, iconName). Runs as a dump phase, tracking applied files in meta.migrations_applied so only newly-present files act. The first run records a baseline and applies nothing (existing blocks already reference current names), so renames fire only on a genuine future mod update. Lua migrations are runtime save-state scripts (can't rename prototypes) and are out of scope.