deploy: pull prebuilt registry images in compose (IMAGE_TAG)

Point the `app` and `bot` services at the images published to the Gitea
registry by the build-images workflow, so deploys pull instead of building:

  image: gitea.whitlocktech.com/uom/website-app:${IMAGE_TAG:-latest}
  image: gitea.whitlocktech.com/uom/website-bot:${IMAGE_TAG:-latest}

`build:` is kept, so `up --build` still works locally; the server runs
`docker compose pull && up -d`. IMAGE_TAG defaults to `latest` for routine
deploys and pins to an immutable `sha-<7>` build for reproducible deploys /
rollback — no per-deploy compose edits. Documented in .env.example + README.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0114TpmrNW4wNXsHq5CR72jQ

README.md

@@ -111,6 +111,20 @@ docker compose up -d --build
 - Logs: `docker compose logs -f app` (and `./logs/app.log` on the host)
 - Stop: `docker compose down` (add `-v` to also wipe the database + uploads volumes)
 
+**Deploy prebuilt images (no local build).** Every merge to `main` publishes the
+`app` and `bot` images to the Gitea container registry
+(`.gitea/workflows/build-images.yml`), so on the server you can pull instead of
+building:
+
+```bash
+docker compose pull && docker compose up -d          # IMAGE_TAG defaults to `latest`
+# pin a specific build (reproducible deploy / rollback):
+IMAGE_TAG=sha-042a151 docker compose pull && docker compose up -d
+```
+
+`build:` is kept in `docker-compose.yml`, so `docker compose up -d --build` still
+works if you'd rather build locally.
+
 ### Option B — Local development (hot reload)
 
 Run the API and the Vite dev server separately. The Vite server proxies `/api` and `/uploads`