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/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.