Containerize for independent deployment

Adds a Dockerfile, nginx config, docker-compose.yml, and a Gitea Actions
workflow (mirroring goonk's), so rack builds and ships as its own image
rather than being embedded in goonk-cv's build - deploys stay fully
decoupled. Targets a subdomain, not a goonk.se subpath, to avoid needing
path-prefix rewriting kept in sync across the build, edge proxy, and
container.

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

README.md

@@ -85,26 +85,40 @@ uninstall) re-render immediately via a direct callback instead of waiting
 on that interval, and it's skipped entirely while a `<select>` has focus so
 the service-picker dropdown doesn't get yanked shut mid-render.
 
-## Deploying as a subdirectory (e.g. goonk.se/rack)
+## Deployment
 
-`npm run build` emits root-relative asset URLs (`/assets/...`), which only
-works if rack is served from the domain root. To deploy it under a
-subpath instead, use:
+rack is its own container — deployed independently of `goonk`/`goonk-cv`,
+same pattern as every other project on this host: a `Dockerfile` builds
+the static site and serves it via nginx, `.gitea/workflows/docker.yml`
+builds and pushes that image to the Gitea registry on every push to
+`main`, and `docker-compose.yml` is the host-side reference for running
+it. The CI workflow needs a repo secret named `TKNTKN` (a Gitea PAT with
+`packages:write`) — same requirement as `goonk`'s own workflow, set under
+Settings → Secrets.
+
+Served from its own subdomain (e.g. `rack.explewd.com`), not a subpath of
+goonk.se — that keeps the build completely vanilla (root-relative asset
+URLs work as-is, no `--base` flag needed) and means the edge nginx just
+needs one new `server_name` block or NPM proxy host pointing at whichever
+port `docker-compose.yml`'s `HOST_PORT` exposes (`5677` by default — no
+`--base=/rack/`/path-prefix plumbing required, unlike a subpath
+deployment would need).
 
 ```bash
-npm run build:subpath   # vite build --base=/rack/
+docker build -t rack .
+docker run -d -p 5677:80 rack   # or: docker compose up -d
 ```
 
-That rewrites `dist/index.html`'s asset URLs to `/rack/assets/...`. Drop
-the resulting `dist/` contents into the host site wherever it serves
-static files under `/rack/` — for the `goonk` Astro site specifically,
-that's `goonk/public/rack/` (Astro copies `public/` verbatim into its own
-`dist/` at build time, and its nginx config already does a
-`try_files $uri $uri/ /index.html` fallback, so no nginx changes are
-needed - existing `public/waste`, `public/pitwall` follow the same
-one-subdir-per-project convention). `rack`'s own `localStorage` key
-(`rack-save-v1`) is namespaced, so it won't collide with anything else
-served from the same origin.
+`rack`'s own `localStorage` key (`rack-save-v1`) is namespaced regardless
+of URL shape, so it won't collide with anything else on the same origin.
+
+If a subpath deployment (`goonk.se/rack`) is wanted later instead, use
+`npm run build:subpath` (`vite build --base=/rack/`) — it rewrites
+`dist/index.html`'s asset URLs to `/rack/assets/...`. That requires the
+edge proxy to forward the `/rack/...` path through *unchanged* (not
+strip the prefix) and the container to serve files at that same
+sub-path — more moving parts to keep in sync than the subdomain route
+above, which is why subdomain is the current choice.
 
 ## Tests