PR previews can't exercise the API — give each preview (or a shared staging env) its own database #74

Problem

Vercel deploys a real per-PR preview for the client (web/client/vercel.json + Vercel's git integration), but the server has no equivalent per-PR deployment — .github/workflows/pr-docker.yml only builds the server Docker image on a backend-touching PR (push: false), it never runs or publishes it anywhere reachable.

Every client preview instead talks to one fixed, shared, long-lived backend:

// web/client/src/utils/api.ts:3-6
if (__VERCEL_ENV__ === 'preview') {
  return 'https://api-testing.albionroads.live';
}

That backend (server-testing in provisioning/docker-compose.yml, deployed via .github/workflows/deploy-testing.yml on pushes to the testing branch, documented in docs/development.md) does exist and is actively used by every PR preview simultaneously — it isn't unused, but it is a single shared instance, not per-PR and not ephemeral. That means:

• Concurrent PRs that touch the DB schema or seed/rely on specific data can collide or interfere with each other's previews.
• It carries whatever data has accumulated on it over time, rather than a clean slate.
• A PR that needs a schema migration to demo correctly can't safely deploy its server changes there without affecting every other preview in flight.

Suggested direction

• Provision an ephemeral (or single shared, but cleanly resettable) Postgres database per preview build, modeled on the existing local-dev setup (provisioning/docker-compose.yml's plain postgres:16-alpine db service + scripts/start-local-db.sh).
• Schema setup should be effectively free: initDb() (web/server/src/db.ts:31-48) already runs all migrations automatically via node-pg-migrate on server boot (index.ts calls await initDb()) — a fresh empty database + any running server instance against it is enough, no manual migration step.
• Wire a per-PR (or freshly-reset shared staging) DATABASE_URL into whichever server instance backs that preview, and point the corresponding Vercel preview's API base URL at it.
• Note CI itself doesn't currently stand up a real Postgres either — test.yml mocks pg.Pool (web/server/test/testApp.ts) — so this would be the first "real database" automation in the pipeline; the docker-compose db service is the natural template.

This is infra/CI work, not a small patch — flagging for scoping/prioritization rather than proposing a specific implementation.