Docs: both hosts deploy from CI; the site table reads v0.5.2

docs/operations.md

@@ -124,3 +124,29 @@ garage bucket allow --read --write <site>-attachments --key <site>-portal-upload
 then `GARAGE_S3_ENDPOINT`, `GARAGE_ACCESS_KEY`, `GARAGE_SECRET_KEY` and
 `GARAGE_UPLOADS_BUCKET` in that instance's env. Unset, an upload field
 fails closed rather than appearing to work and storing nowhere.
+
+## Who deploys what
+
+Both hosts deploy from CI now, and a rollout is the same commit either
+way: bump `PORTAL_RELEASE` in the site's own content repo.
+
+| | runner | how it is allowed to |
+|---|---|---|
+| ergo | `runs-on: bare` | the runner is privileged and writes `/srv/app` and `/etc/app` itself |
+| kasse | `runs-on: fish` | the runner is not privileged. It may run one root script, `/usr/local/bin/deploy-portal-instance`, which checks the instance against a fixed list and the tag against a release-tag shape before touching anything |
+
+The kasse grant is a single sudoers line
+(`/etc/sudoers.d/30-portal-deploy`). It exists so a workflow can pick
+which of three known instances gets which published portal tag, and
+nothing else.
+
+Both paths health-check the instance afterwards **without** a forwarded
+header. A check that sends the header Caddy would send cannot tell you
+the site is broken for everything that is not Caddy, which is how
+v0.5.1 reached a host.
+
+`IRIS_RELEASE` in a repo's lint workflow should equal its
+`PORTAL_RELEASE`. Bump it only once iris's own publish job has attached
+the binary for that tag - portal's release tags iris, but iris builds
+and uploads on its own run, and a pin bumped in between fails the lint
+on a download that is not there yet.