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).