An older build starts on a database a newer build migrated #518

What happens

A J5 Code build that is older than the database opens it without complaint and fails later, at query time. Nothing compares the database's migration history with what the running build knows before the server starts work.

This is the second half of #517. #517 is about two servers on one home at the same time. This one is sequential: run a nightly, quit it, open stable again. Jackson (2026-10-10) wants both solved together, as a stack, because stopping two owners at once is half a fix if the one owner left cannot read the database.

What exists today

• apps/server/src/persistence/Migrations.ts (upstream) already finds recorded migrations that are "unknown to this build" after migrating. It logs a warning and carries on.
• J5's ledger migrator (apps/server/src/j5/a2a/Migrations.ts) has no check.
• apps/server/src/j5/persistence/UpstreamMigrationCompatibility.ts refuses three histories that are too old to upgrade. That is the opposite direction.
• j5 update and j5 service install refuse an older package without --allow-downgrade. That compares version numbers at install time and never reads the database. The Mac app does not go through it.
• The pre-migration snapshot (feat(j5): nightly releases from j5/main, with a snapshot before any migration #511) and the rollback steps in docs/j5/runbooks/macos-packaging.md are the current protection. Both runbooks state that there is no downgrade guard.

What a fix has to guarantee

• A server refuses to start when either migration history (upstream's or J5's ledger) records a migration this build does not have. The check comes before the snapshot and before any migration runs.
• The person is told why, and what to do: update to the newer build, or restore the pre-migration snapshot.
• In the Mac app this is a dialog, not the silent restart loop a failing bundled server causes today.

Open questions

• Turning upstream's warning into a refusal changes upstream's startup behavior, so it needs a register entry.
• Upstream PR fix(server): enforce one database owner and guard update rollback pingdotgg/t3code#16102 adds an exit code (78) that makes the desktop app stop retrying and show a dialog. If J5 takes that PR for The stable and nightly Mac apps run at the same time and share one database #517, this refusal can reuse the same path.