[klomkling]

Closes coord #41 (filed by propertiezy, target Themia.Data.Migrations).

Problem

FluentMigrator skips migrations already recorded in VersionInfo, so migrate-on-boot is a no-op once applied. The unsafe window is N instances booting simultaneously: all read VersionInfo, all see the same migration pending, and all apply it concurrently. Check-then-apply is not atomic across connections, so they collide on DDL and insert duplicate version rows. Every migrate-on-boot consumer hits this at horizontal scale.

Themia owns the runner entry point, so the fix belongs here rather than wrapped by each app.

Change

ThemiaMigrations.Run now holds the engine's session-level advisory lock over MigrateUp, taken on a dedicated connection. No API change; consumers get the fix on a version bump.

• MigrationLock.cs (new, internal) — pg_advisory_lock / GET_LOCK / sp_getapplock
• Explicit Npgsql / MySqlConnector / Microsoft.Data.SqlClient references (previously transitive via FluentMigrator.Runner.*)

Three decisions departed from the literal request, all deliberate:

1. All three engines, not Postgres-only. Run is engine-generic and all three ship today; a lock that silently no-ops on 2 of 3 is a correctness cliff.
2. On by default. An opt-in flag reproduces the "app authors get this wrong" failure the request wants absorbed.
3. Unbounded wait. A booting instance cannot meaningfully proceed until the one ahead has finished migrating.

Two traps this turns on

The key must be scoped to the database name. The request's attached reference impl (propertiezy PR #30) uses a fixed constant. PostgreSQL advisory locks and MySQL's GET_LOCK are keyed server-wide, not per database, so a fixed key makes two unrelated Themia apps sharing one cluster queue behind each other's migrations. The key derives from the live connection.Database, which also avoids per-engine connection-string parsing. sp_getapplock is natively database-scoped but takes the same scoped name for uniformity.

Not string.GetHashCode(). It is randomized per process on .NET — every instance would derive a different key, nothing would contend, and the lock would silently protect nothing, failing in exactly the scenario it exists for while passing any same-process unit test. SHA-256, pinned with golden vectors computed independently of the implementation.

Also: CommandTimeout = 0 on the acquire — the 30s ADO.NET default would abort the wait long before a slow migration ahead had finished.

MigrationLock is kept internal on purpose: a public primitive invites RunExclusive(() => Run(...)), which self-deadlocks (the inner call opens a different connection; these are session locks).

Test plan

• Falsified before trusting: removing the acquire makes RunExclusive_ShouldBlockASecondCaller fail (second caller runs straight through) while the cross-database test still passes — the test discriminates precisely.
• 10/10 integration tests against real containers on all three engines — blocks-a-second-caller and no-contention-across-databases each, plus a 6-instance concurrent ThemiaMigrations.Run asserting exactly one VersionInfo row.
• 15/14 unit tests (net10.0/net8.0) covering key derivation against golden vectors and the MySQL 64-char lock-name cap.
• Clean full-solution build, 0 warnings (TreatWarningsAsErrors, no RS0016); full unit suite green.

Not included

Version bump and publish — the version is monorepo-shared, so the release is a whole-set decision. CHANGELOG entry sits under [Unreleased].