chore(deploy): single-container Dockerfile, Caddy, and Unraid template

Builds the container the "1 container" decision (D15) actually needs, which
D15 itself deferred as follow-up work: Caddy + the FastAPI app + the static
SvelteKit build in one image, SQLite on a mounted volume. See docs/DECISIONS.md
D16 for the specific choices and why (entrypoint-run migrations instead of a
separate deploy-pipeline step, tini + a small supervisor script instead of
s6-overlay/supervisord, copying the Caddy binary out of its official image).

Removes apps/api/Dockerfile and apps/web/Dockerfile from the old 4-container
compose plan (PR #4, closed as superseded) — the root Dockerfile replaces both
with one multi-stage build.

deploy/unraid-template.xml turns VELODROME_PUBLIC_URL, VELODROME_SECRET_KEY,
etc. into fillable Unraid Community Applications web UI fields, per the
earlier decision to keep config there instead of a .env file.

.gitea/workflows/release.yml builds and pushes the image to the Gitea registry
on a version tag or manual dispatch; it does not touch the running container.

Verified by actually running the built image, not just building it: the
health endpoint responds through Caddy's proxy, the SPA serves with working
client-route fallback, alembic ran and produced a real (non-empty) SQLite file
under /data, the process runs as the non-root velodrome user, and killing the
uvicorn process brings the whole container down (exit 143) rather than
leaving Caddy serving alone — confirming the entrypoint's coupled-lifetime
behavior actually holds, not just that it reads correctly.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01R2ZKeWkZV7ehf7fivrAkkG

apps/api/Dockerfile

@@ -1,31 +0,0 @@
-# syntax=docker/dockerfile:1
-FROM python:3.12-slim AS builder
-
-RUN pip install --no-cache-dir uv
-
-WORKDIR /app
-COPY pyproject.toml uv.lock ./
-# Split into two syncs so dependency installation caches independently of source changes: this
-# first one installs only dependencies (--no-install-project), so touching velodrome/ doesn't
-# invalidate this layer.
-RUN uv sync --frozen --no-install-project --no-dev
-
-COPY velodrome ./velodrome
-COPY alembic ./alembic
-COPY alembic.ini ./
-# Now install the project itself into the same venv.
-RUN uv sync --frozen --no-dev
-
-FROM python:3.12-slim AS runtime
-
-RUN groupadd --system velodrome && useradd --system --gid velodrome --create-home velodrome
-WORKDIR /app
-COPY --from=builder /app /app
-ENV PATH="/app/.venv/bin:$PATH"
-USER velodrome
-
-EXPOSE 8000
-
-# Migrations run as an explicit step before this in deploy.yml (see docs/PLAN.md) — never from
-# the entrypoint, so a failed migration fails the deploy visibly instead of crash-looping here.
-CMD ["uvicorn", "velodrome.app:app", "--host", "0.0.0.0", "--port", "8000"]

apps/web/Dockerfile

@@ -1,36 +0,0 @@
-# This image's ONLY purpose is to produce /app/build — the static SPA output
-# (HTML/CSS/JS/manifest/service worker). There is no Node runtime in
-# production: per docs/PLAN.md's "Stack" and "The PWA decision", Caddy serves
-# these files directly and proxies /api/* to the FastAPI backend. This image
-# is never run as a long-lived container in production.
-#
-# Build context: this directory (apps/web), e.g. `docker build -f
-# apps/web/Dockerfile apps/web`.
-#
-# How deploy/ is expected to consume this: build this image, then copy its
-# /app/build contents out into a location the `caddy` service in
-# deploy/docker-compose.yml bind-mounts — either via a multi-stage
-# `COPY --from=bennybergle/velodrome-web:<tag> /app/build /srv/web` in the
-# Caddy image build, or with a one-shot `docker create` + `docker cp` /
-# `docker run --rm -v ...` step in the deploy pipeline that dumps /app/build
-# into a named volume or bind-mounted host directory before `caddy` starts.
-# Picked this over a scratch/busybox "artifact-holder" final stage because a
-# single builder stage is simpler to reason about and there's nothing here
-# that needs to run — the consumer only ever needs the files, not a container.
-# The deploy/ agent may adjust this to whatever's simplest for the compose
-# setup; this is just the contract (build → /app/build).
-
-FROM node:22-slim AS builder
-
-WORKDIR /app
-
-# Install dependencies first, isolated from source changes, for layer caching.
-COPY package.json pnpm-lock.yaml ./
-RUN corepack enable && corepack prepare pnpm@9 --activate \
-	&& pnpm install --frozen-lockfile
-
-COPY . .
-RUN pnpm run build
-
-# Nothing further: /app/build is the artifact. No CMD/ENTRYPOINT — this image
-# is not meant to be run.

apps/web/README.md

@@ -77,23 +77,11 @@ false`, and `vite.config.ts` configures `@sveltejs/adapter-static` with `fallbac
 - **Styling.** Plain CSS (`src/app.css`), CSS custom properties for theming, `prefers-color-scheme`
   for dark mode. No Tailwind — kept the dependency surface small for this scaffolding phase.
 
-## Dockerfile
+## Docker build
 
-This image's **only** purpose is to produce `/app/build` (the static SPA output) as a buildable
-artifact — see the comment block at the top of `Dockerfile` for the full rationale. There is no
-Node runtime in production; Caddy serves the built files directly and proxies `/api/*` to the API
-container (`docs/PLAN.md`, "Service topology"). This image is never run as a long-lived container.
-
-Build it with the `apps/web` directory as context:
-
-```sh
-docker build -f apps/web/Dockerfile -t velodrome-web-build apps/web
-```
-
-How `deploy/` is expected to consume it (my assumption — the `deploy/` work is happening in a
-parallel worktree, so this may get adjusted there): a multi-stage `COPY --from=velodrome-web-build
-/app/build /srv/web` in whatever image serves Caddy, or a one-shot `docker create` +
-`docker cp` / bind-mount step in the deploy pipeline that populates the volume Caddy reads from
-before it starts. Went with a single plain builder stage (no `scratch`/`busybox` artifact-holder
-final stage) because nothing here needs to _run_ — the only thing anyone needs from this image is
-the files in `/app/build`, and a second stage would add complexity without adding anything.
+There is no `apps/web/Dockerfile` anymore. Per D15/D16 (`docs/DECISIONS.md`), the whole app ships
+as one container, so building this SPA is a stage in the root `Dockerfile`
+(`web-builder`, `apps/web` as its `COPY` source), not a standalone image — the built output
+(`/app/build`) is copied straight into the runtime stage at `/srv/web`, which is what the root
+`Dockerfile`'s Caddy config (`deploy/Caddyfile`) serves. There is no Node runtime in production.
+See `deploy/README.md` for the actual single-container build/run instructions.