fix(migrations): leave an index another instance is still building alone

A concurrent build that is still running is INVALID with its migration not
yet finished, exactly like a failed one. With the web and worker roles in
two containers, the second boot dropped the index the first was building,
which cancelled the first one's migration and left it failed until someone
resolved it by hand.

The check and the drop now run in one transaction that first takes Prisma's
migration lock without waiting and does nothing when another instance holds
it; an index Postgres reports as being built is never dropped. One
transaction also keeps lock_timeout on the statement it bounds behind a
transaction pooler, and the applied-migrations lookup quotes the schema, so
a mixed-case schema no longer reads as having none applied.

docs/ops/deploy.md

@@ -119,6 +119,12 @@ boot drops that INVALID index before it migrates, logs
 `dropped the invalid index …`, and the re-run builds it again. Without that
 step the re-run would find the index by name and skip it.
 
+A build that is still running looks the same, INVALID with its migration not
+yet finished. The boot therefore leaves every index alone while another
+instance is migrating (it checks Prisma's migration lock first) and never
+drops an index Postgres reports as being built, so a second container that
+starts during the first one's migration cannot cancel it.
+
 An INVALID index whose migration is already recorded applied is not touched at
 boot. The boot names it on stderr with `WARNING — index … is INVALID`; rebuild
 it with `REINDEX INDEX CONCURRENTLY "<index>";` when the database is quiet.