Christophe Vila
46ad8a7e08
Every existing migration test opens a brand-new DB via store.Open, which runs migrations 0001-0025 in one uninterrupted pass over an empty database -- so migrations 0023/0024/0025's table-rebuild (create-new/copy/ drop-old/rename-into-place) never had any real pre-existing rows to carry across, and no test proved that a genuinely in-use single-tenant install (real workout_kinds, real synced activities, kind_assignments referencing workout_kinds by FK) upgrades safely. TestRebuildMigrationsPreserveForeignKeyReferences manually applies migrations up to (but not including) the three rebuilds, inserts rows simulating that pre-existing install, applies the rebuilds, then verifies the kind_assignments row still resolves to the correct workout_kinds row by name, and that FK enforcement is genuinely back on afterward (a bogus workout_kind_id is rejected). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>