fix(db): acquire postgres advisory lock during migration execution (#1440)

[Awosdot]

What changed

• Updated backend/src/db/migrate.ts to acquire a PostgreSQL advisory lock (pg_advisory_lock(727727)) prior to executing prisma migrate deploy, releasing it in a finally block[cite: 11].
• Added a 5-second retry mechanism if the lock is initially unavailable during deployment races[cite: 11].
• Added migration_lock_acquired metric logging upon successful lock acquisition[cite: 11].
• Added unit/integration tests simulating concurrent migration execution to assert single execution and prevent P3005 errors[cite: 11].

Why

When multiple application pods start concurrently, racing prisma migrate deploy operations lead to P3005 migration already applied database errors and service crash loops[cite: 11]. Using Postgres advisory locks guarantees mutual exclusion across pod instances on startup[cite: 11].

How tested

• Ran concurrent execution test suite confirming only one process executes migrations while secondary processes wait/defer safely[cite: 11].
• Confirmed single-pod startup and existing test workflows complete without regression[cite: 11].

Closes

Closes #1440

[drips-wave]

@Awosdot Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits