feat(deploy): compose stack, Caddy, and the release/deploy pipeline

Phase 0 deployment: three-service docker-compose.yml (caddy, api, db), a
Caddyfile that proxies /api/* to the api service and serves the SPA with
index.html fallback, and two Gitea Actions workflows (release.yml builds and
pushes both images on a v* tag or manual dispatch; deploy.yml is manual-only
and rolls them out to the Unraid host).

The non-obvious part is the Docker-outside-of-Docker constraint on this
act_runner setup: job containers share the host's Docker daemon over the
socket but do NOT share its filesystem, so any command whose correctness
depends on a client-side local path (docker cp to a host path, mv/rm -rf on
a host path, a bind-mount source path on a `docker run` command line issued
from inside a job) silently operates on the ephemeral job container's own
throwaway filesystem instead. Two things are safe: a bind mount declared in
a compose file's `volumes:` block (resolved by the daemon when `docker
compose up` creates the service — this is why db's pgdata bind mount is
fine), and a named volume populated by a one-shot `docker run` whose
*command* does the copying (this is why the web image's static build output
goes into a `web_build` named volume via `docker run -v ... sh -c 'cp -a
...'` in deploy.yml, rather than any `docker cp`).

Local verification (see PR description for full detail) caught a real bug:
`docker compose run api alembic upgrade head` needs
VELODROME_DB_APP_PASSWORD/VELODROME_DB_AUTH_PASSWORD as container env vars
to create the two runtime roles, but --env-file alone doesn't inject them
since the api service's permanent environment block deliberately omits them
(least-privilege — the long-running app should never need role-creation
passwords). Fixed by passing them as explicit -e overrides on the migration
step, same as VELODROME_DATABASE_URL_MIGRATE.

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

deploy/docker-compose.yml

@@ -0,0 +1,67 @@
+# Phase 0 deployment stack: caddy + api + db.
+#
+# Deliberately NOT included yet: a `worker` service running `procrastinate worker`. Nothing in
+# Phase 0/1 enqueues background jobs — that arrives with the ingestion pipeline. Adding it now
+# would just be an idle container. See docs/PLAN.md's "Service topology".
+#
+# The `web` image (apps/web/Dockerfile) is built and pushed by release.yml but never runs as a
+# service here — its only output is a static /app/build directory. deploy.yml populates the
+# `web_build` named volume from it with a one-shot `docker run`, entirely server-side against the
+# Docker daemon, before `caddy` starts. See deploy.yml for why this has to be done that way
+# (Gitea's runners are Docker-outside-of-Docker: job containers don't share a filesystem with the
+# host, so a client-side host path on a `docker cp`/`docker run -v` issued from inside a job
+# silently resolves against the wrong filesystem and does nothing).
+#
+# Invoke with: docker compose --env-file /mnt/user/appdata/velodrome/.env -f deploy/docker-compose.yml ...
+
+services:
+  caddy:
+    image: caddy:2-alpine
+    restart: unless-stopped
+    ports:
+      - "8090:80"
+    volumes:
+      - ./Caddyfile:/etc/caddy/Caddyfile:ro
+      - web_build:/srv/web:ro
+    depends_on:
+      - api
+
+  api:
+    image: 192.168.0.3:3000/bbergle/velodrome-api:${TAG:-latest}
+    restart: unless-stopped
+    environment:
+      # Superuser DSN (VELODROME_DATABASE_URL_MIGRATE) is deliberately NOT here — the
+      # long-running app process must never hold superuser DB credentials. It's passed only as a
+      # one-off `-e` override on the migration step in deploy.yml. See apps/api/README.md's "Why
+      # two database connections".
+      VELODROME_DATABASE_URL_APP: ${VELODROME_DATABASE_URL_APP}
+      VELODROME_DATABASE_URL_AUTH: ${VELODROME_DATABASE_URL_AUTH}
+      VELODROME_SECRET_KEY: ${VELODROME_SECRET_KEY}
+      VELODROME_ENVIRONMENT: production
+      VELODROME_PUBLIC_URL: http://192.168.0.103:8090
+    depends_on:
+      db:
+        condition: service_healthy
+
+  db:
+    image: postgis/postgis:16-3.4
+    restart: unless-stopped
+    environment:
+      POSTGRES_USER: postgres
+      POSTGRES_PASSWORD: ${POSTGRES_SUPERUSER_PASSWORD}
+      POSTGRES_DB: velodrome
+    volumes:
+      # Bind-mounted directly (not a named volume) — this is safe under DooD because it's
+      # resolved by the Docker daemon when `docker compose up` creates the service, not by any
+      # client-side path handling inside a job container. See the header comment above.
+      - /mnt/user/appdata/velodrome/pgdata:/var/lib/postgresql/data
+    healthcheck:
+      test: ["CMD-SHELL", "pg_isready -U postgres"]
+      interval: 5s
+      timeout: 5s
+      retries: 10
+
+volumes:
+  # Populated from the `web` image's /app/build by a one-shot `docker run` in deploy.yml — never
+  # mounted read-write, never written to by any long-running service.
+  web_build: