feat(db): adopt prisma migrate for a real migration history

[skipbit]

Replaces the db push dev workflow with committed migrations, so a clone comes
up with a schema built from versioned SQL rather than a schema diff applied at
boot. This closes the last "not shippable" gap in the database story: there is
now a real migration history to deploy.

What changes

• prisma/migrations/20260826022052_init — the initial migration, generated
  from the current schema. RateLimit.expiresAt keeps its TIMESTAMPTZ(3), and
  the account/session foreign keys keep ON DELETE CASCADE.
• Both compose stacks apply pending migrations with migrate deploy on start,
  so a fresh clone comes up migrated. migrate deploy is non-interactive and
  idempotent; migrate dev is not, and would try to reset a drifted database.
• A schema change is turned into a migration inside the running container, so
  the host still needs no Node:

  docker compose exec app npx prisma migrate dev --name add_projects
  docker compose exec app npx prisma generate

• New CI job migrations applies the migrations to a real Postgres, then
  runs migrate diff --exit-code against schema.prisma. A schema edit
  committed without its migration exits 2 and fails the job.
• Docs and the agent/command definitions are updated so the workspace no longer
  teaches db push.

Two pre-existing defects fixed along the way

• The prod stack could never start. docker-compose.prod.yml passed
  db push --skip-generate, a flag Prisma 7 removed, so the migrate service
  always exited 1 and app never met service_completed_successfully. No CI
  path exercised the prod compose file, so this went unnoticed since the
  Prisma 7 upgrade.
• The dev and prod stacks shared a namespace. Both files resolved to project
  name slipway, so they shared the slipway-app image tag and the
  slipway_pgdata volume. Building the prod stack replaced the dev image — and
  the slim runner has no Prisma CLI, so the next dev start fell back to fetching
  an unpinned prisma prerelease from the registry. down -v on prod also
  dropped the dev database. The prod stack is now its own project,
  slipway-prod.

Verification

• npm run lint, npx tsc --noEmit, npm run test (23 passed), npm run build
• Clean docker compose up: migration applied, app 200
• Repeat start without -v: No pending migrations to apply., app 200
• Prod stack end to end: migrate exits 0, app 200
• Drift detection: adding a model without a migration makes migrate diff exit 2
• Namespace fix: after a prod --build, the dev image digest is unchanged and
  down -v removes only slipway-prod_pgdata

Note for after merge

The new migrations job has to be added to the branch protection rule as a
required status check; it is not one automatically.