runLcmMigrations() was executing schema changes and backfill updates outside a top-level transaction, so concurrent startup processes could repeatedly contend on SQLite write locks and hit SQLITE_BUSY. This change serializes the migration run behind one exclusive transaction so later processes wait once, then observe an already-migrated database.

• Migration transaction boundary

  • Wrap runLcmMigrations() in BEGIN EXCLUSIVE / COMMIT / ROLLBACK
  • Keep existing idempotent migration steps unchanged inside the new outer transaction
  • Ensure failures unwind the full migration, not just individual backfill savepoints

• Nested backfill compatibility

  • Update backfillMessageIdentityHashes() to reuse an existing transaction instead of issuing its own BEGIN
  • Preserve its existing batching behavior when called outside a transaction

• Regression coverage

  • Add a migration test that asserts the run opens exactly one BEGIN EXCLUSIVE
  • Tighten the failure-path test to verify a migration error rolls back all schema and migration-state changes, not only backfilled row data

• Release note

  • Add a patch changeset for the migration-locking fix

Example of the new transaction shape:

export function runLcmMigrations(db: DatabaseSync, options?: { fts5Available?: boolean }): void {
  db.exec(`BEGIN EXCLUSIVE`);
  try {
    // schema creation, ALTER TABLEs, backfills, FTS setup
    db.exec(`COMMIT`);
  } catch (error) {
    db.exec(`ROLLBACK`);
    throw error;
  }
}