Run db:migrate automatically before every Railway deploy

The 2026-07-06 prod outage was a missed manual migration: the 0002
job_events migration never ran against prod, so the worker crash-looped
on every job. Make the deploy pipeline own it:

- railway.json sets `npm run db:migrate` as the pre-deploy command.
  Railway runs it with the service's env before starting the new
  deployment; a failed migration fails the deploy and the old version
  keeps serving.
- runMigrations() now serializes on a Postgres advisory lock so api and
  worker pre-deploys firing off the same push can't race Drizzle's
  journal writes.
- DEPLOY.md: document the automatic path; keep the manual command for
  first-time setup.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/DEPLOY.md

@@ -12,14 +12,20 @@ Postgres and S3-compatible storage. The recommended OSS-friendly stack:
 ## 1. Database (Neon)
 
 1. Create a Neon project; copy the pooled connection string.
-2. Apply migrations (from CI/CD or locally):
+2. Migrations run **automatically before every Railway deploy**: the repo's
+   `railway.json` sets `npm run db:migrate` as the pre-deploy command, which
+   Railway executes (with the service's env, so `DATABASE_URL` is present)
+   before starting the new deployment. Re-running is a no-op for anything
+   already applied, and concurrent runs (api + worker deploying off the same
+   push) serialize on a Postgres advisory lock. A failed migration fails the
+   deploy — the old version keeps serving.
+
+   To apply migrations manually (first-time setup, or outside Railway):
    ```bash
    DATABASE_URL='postgres://...neon.../ditto_site?sslmode=require' npm run db:migrate
    ```
-   Run this on every deploy that changes `packages/db/migrations`. Drizzle tracks
-   applied migrations in the database, so re-running is a no-op for anything
-   already applied. (Alternatively, apply a single migration by piping its SQL
-   through `psql`/the Neon CLI — but prefer `db:migrate`, which also records the
+   (Alternatively, apply a single migration by piping its SQL through
+   `psql`/the Neon CLI — but prefer `db:migrate`, which also records the
    journal entry so future runs stay consistent.)
 
    Current migrations: `0000` core tables, `0001` signup tokens,