Prevent duplicate migration-stamp failures during concurrent startup

[jadch]

Problem

runSqliteDataMigrations reads the completion ledger once at startup. When multiple hosts boot against the same database, they can all observe a migration as pending, complete its idempotent body, and then race to insert the same ledger stamp. The first insert wins; every other host currently fails startup on the duplicate primary key.

This failure pattern appeared on the Cloudflare/D1 host during concurrent MCP initialization immediately after deployment: requests failed while the shared ledger was converging, then passed once every migration was stamped.

Fix

Stamp completed migrations atomically with:

INSERT INTO data_migration (name, time_completed)
VALUES (?, ?)
ON CONFLICT(name) DO NOTHING

The conflict target is only the migration name, so a concurrent runner that loses the same-stamp race converges without a startup failure while unrelated database errors still surface. Resolving the conflict in the write itself also avoids a cross-session verification read, whose visibility could lag another D1 session's commit.

The migration-body contract remains unchanged: bodies must be idempotent because they may rerun after a crash or concurrent startup.

Tests

• deterministic concurrent-runner regression against real in-memory libSQL: both runners read an empty ledger, both bodies complete, and exactly one stamp remains;
• non-conflict stamp failures still surface with their original cause;
• concurrent regression passed 100/100 repeated runs;
• bun run format:check;
• bun run lint;
• bun run typecheck (43/43 tasks);
• full non-E2E suite via isolated HOME=$(mktemp -d) bun run test (37/37 tasks).

[jadch]

Reopening: a merged downstream vendor-sync PR accidentally referenced this using GitHub’s fix: closing-keyword syntax, so GitHub auto-closed this PR. The implementation and validation here are unchanged.

[jadch]

Refreshed this onto current main (541549a5) without rebasing or force-pushing. The focused migration suite passes locally (8/8), and fresh CI passed format, lint, typecheck, unit tests, three cloud E2E shards, and both build checks.

The self-host red is the exact failure already present on current main: main CI returns the new generic invalid_grant reconnect detail from #1507 while mcp-oauth-reconnect-health.test.ts still expects Grant not found. This PR does not touch that path.

Cloud shard 3 also hit a separate test-server failure: after its earlier scenarios passed, sign-in began returning 500 across seven unrelated scenarios. The same shard passed on #1455's refreshed head. The PR itself remains conflict-free against main.