Automate deployment: push to main now deploys itself

Registered a repo-scoped self-hosted runner (hcl-local-deploy) directly on
the box serving hcl.archipelago-foundation.org, running in host (not
docker) execution mode. Deploy is a plain local rsync — no SSH keys or
remote credentials needed, since the runner already has filesystem access
to the docroot. Runs as the debian user with no sudo; docroot ownership
was changed from www-data to debian so this works without any privilege
escalation (nginx only needs read access to serve it).

ci.yml now runs on pull_request only — deploy.yml already validates before
deploying on push to main, so running both on every push would just
duplicate the check.

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

README.md

@@ -6,8 +6,7 @@ what didn't, and why. Model, CPU, RAM, storage, and WiFi chip for every
 report, since WiFi chipsets are consistently the thing most likely to bite
 someone doing an install on repurposed hardware.
 
-**[Browse the list →](https://hcl.archipelago-foundation.org)** (once deployed —
-see [Deployment](#deployment) below)
+**[Browse the list →](https://hcl.archipelago-foundation.org)**
 
 ## Why this exists
 
@@ -73,11 +72,33 @@ python3 -m http.server 8000 --directory site
 
 ## Deployment
 
-Not yet deployed. This is a static site (`site/`) with no backend — any
-static host works (the same nginx-in-front-of-a-container pattern archy's
-other apps already use, GitHub/Gitea Pages, or a plain S3-style bucket).
-`scripts/build.py` should run in CI on every push to `main` so `data.json`
-never drifts from the source reports; wiring that up is the next step.
+Live at **https://hcl.archipelago-foundation.org** — a static site (`site/`)
+served by nginx, cert via `certbot certonly --webroot` (same pattern as
+`regress.atobitcoin.io` and this project's other nginx-fronted sites).
+
+Deployment is fully automatic: `.gitea/workflows/deploy.yml` runs on every
+push to `main` on a repo-scoped self-hosted runner (`hcl-local-deploy`,
+label `hcl-deploy`) living on the same box that serves the site — it runs
+`scripts/build.py` and `rsync`s `site/` straight into the docroot, so
+`data.json` can never drift from the source reports. No SSH keys or remote
+credentials involved; the runner has local filesystem access since it's on
+the same machine. `.gitea/workflows/ci.yml` runs the same build/validate
+step on pull requests, on the (separate, shared) `vps2-runner`, so bad data
+gets caught before merge rather than at deploy time.
+
+Runner setup, for reference (repo-scoped registration token from
+Settings → Actions → Runners → Create new Runner):
+
+```bash
+gitea-runner register --no-interactive \
+  --instance <gitea-url> --token <token> \
+  --name hcl-local-deploy --labels "hcl-deploy:host" \
+  --config /etc/gitea-runner-hcl/config.yaml
+```
+
+running as a systemd service (`gitea-runner-hcl.service`) under a user that
+owns the docroot directly — deliberately not root, and no sudo needed for
+the deploy step itself.
 
 ## License