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

deploy/entrypoint.sh

@@ -0,0 +1,32 @@
+#!/bin/bash
+# Single-container entrypoint (docs/DECISIONS.md D16). Two responsibilities:
+#
+# 1. Run migrations before serving anything. There's no separate "run migrations, then start the
+#    app" step in front of this container the way docs/PLAN.md's original deploy.yml had one for
+#    the 3-container Postgres stack (see apps/api/Dockerfile's history) — a single container has
+#    nowhere else to put that step. `set -e` means a failed migration exits non-zero here, which
+#    still fails startup visibly (Docker/Unraid shows the container as exited/restarting) instead
+#    of silently serving a broken app; that's the property the separate step existed to protect,
+#    preserved by a different mechanism now that there's only one container to do it in.
+# 2. Run uvicorn and Caddy as two background processes and tie their lifetimes together: if either
+#    one dies, kill the other and exit with its status, so Docker/Unraid restarts the whole
+#    container. Two half-alive processes (API up, web serving stale/nothing, or vice versa) is a
+#    worse failure mode than a clean restart.
+set -euo pipefail
+
+alembic -c /app/alembic.ini upgrade head
+
+# uvicorn binds loopback only — Caddy is the sole process with an exposed port, and the sole
+# thing that talks to uvicorn (see deploy/Caddyfile's reverse_proxy target).
+uvicorn velodrome.app:app --host 127.0.0.1 --port 8000 &
+API_PID=$!
+
+caddy run --config /etc/caddy/Caddyfile --adapter caddyfile &
+CADDY_PID=$!
+
+trap 'kill -TERM "$API_PID" "$CADDY_PID" 2>/dev/null || true' TERM INT
+
+wait -n "$API_PID" "$CADDY_PID"
+EXIT_CODE=$?
+kill -TERM "$API_PID" "$CADDY_PID" 2>/dev/null || true
+exit "$EXIT_CODE"