fix(server): a migration id clash stops startup with a clear error instead of a crash loop

[shivamhwp]

If a database already has a different migration recorded at id 55, for example because main ships its own migration 55 before V2 lands, V2 silently skips its own OrchestrationV2 schema migration. The server then crash-loops on every start with no such column: application_event_version, and the only clue is a warning that already appears in the logs.

This happens because the migrator skips every id up to the highest one it has recorded and never checks the names. runMigrations now checks V2's ids (55 and up) before migrating. If any would be skipped, startup stops with one error that names them, and nothing is migrated. Lower ids keep the existing warning only: #11639 found a real user database with a site-local migration there that still works, and it has to keep booting. A database that a newer V2 build migrated further, such as one with an extra 57, still starts.

Before, on a copy of real data with a fake 55_FutureMainMigration row:

WARN: Database migration history diverges from this build; recorded migration ids are skipped, not reconciled by name.
  divergent: [ '55:FutureMainMigration (this build: OrchestrationV2)' ]
ERROR: EventSinkStreamError: Failed to stream orchestration V2 events.
  ... Error: no such column: application_event_version

Migration 56 had also been applied to the broken database.

After, with the same copy:

ERROR: MigrationError: This database recorded other migrations at ids this build needs for its own schema, so it would skip 55_OrchestrationV2 (recorded: FutureMainMigration). ...

The database was left untouched. An unmodified copy of the same data boots normally.

This doesn't make a clashing database usable. It turns a cryptic crash loop into an error we can act on. The real protection is to number main's migrations above V2's before either ships. Related: #8896 and #9312, which address the same trap for id 45 on main.

Model: Claude Opus 5.5 (Claude Code)

🤖 Generated with Claude Code

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

ℹ️ No successful main baseline artifact is available yet. This run establishes the initial measurement.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	—	4.9 KiB	—	6.8 KiB	✅
Codex	Thread snapshot wire	—	3.7 KiB	—	4.9 KiB	✅
Codex	Live turn WebSocket wire	—	1.1 KiB	—	2.0 KiB	✅
Codex	Live turn WebSocket decoded	—	20.4 KiB	—	29.3 KiB	✅
Codex	Live turn messages	—	1	—	8	✅
Claude	Total thread wire	—	4.9 KiB	—	6.8 KiB	✅
Claude	Thread snapshot wire	—	3.7 KiB	—	4.9 KiB	✅
Claude	Live turn WebSocket wire	—	1.2 KiB	—	2.0 KiB	✅
Claude	Live turn WebSocket decoded	—	20.8 KiB	—	29.3 KiB	✅
Claude	Live turn messages	—	2	—	8	✅

Baseline: unavailable · PR result: 269ac28 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 106.1 KiB
• Claude decoded thread snapshot: 106.4 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

Approvability

Verdict: Approved at 269ac28

Macroscope's review found this PR approvable — This is a focused migration-state bug fix that adds startup validation for conflicting V2 IDs while preserving compatible migration paths. Regression tests cover fresh databases, collisions, site-local earlier migrations, and newer V2 histories; the remaining change is documentation.

Notes:

• Diff unchanged. Approvability was decided on eligibility alone.

^{You can add or adjust custom eligibility rules. Learn more.}

Dismissing prior approval to re-evaluate 872ff2f

Dismissing prior approval to re-evaluate 269ac28