ci: the runner is docker-mode, and a guide for setting one up

`runs-on: ubuntu-latest` stays what it is everywhere else — a disposable
container — and `docker-compose.ci.yml` is now what makes that true: the label
maps to `catthehacker/ubuntu:act-24.04`, job containers share the runner's
network so the cache server is reachable at all, and the host's docker socket is
passed through (`docker_host: automount`) so the image workflow can build.

The failure this is replacing is worth naming, because the symptom does not
point at it: with a **host**-mode runner answering the same label, every job runs
directly on the server as the runner's own user, so the workflows' `apt-get
install` steps fail on permissions — and had they succeeded, CI would have been
installing packages on a host. A workflow cannot tell which kind of runner it
got; only the label map can say.

`docs/gitea-runner.md` is the separate guide: why docker mode, the prerequisites
including Gitea's two `app.ini` settings, the install, how to remove a host-mode
runner (and what to check before you do, since a runner is shared), how to
verify a job really is in a container, why labels cannot be changed without
re-registering, and a table of the failures with their causes.

Also `workflow_dispatch` on the test workflow, so a fresh runner can be proved
from the UI without inventing a commit.

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

README.md

@@ -275,20 +275,25 @@ Gitea Actions, in `.gitea/workflows/`:
 | `docker.yml` | push to master, `v*` tags | builds the image, starts it against SQLite and waits for `/api/health`, then pushes `git.timka.su/timka123/kadence:latest` and `:<short-sha>` |
 | `android-release.yml` | push to master, `v*` tags | `:app`'s suite (81, on the JVM), then the release APK — signed from secrets, with `apksigner verify` printing the certificate it actually used |
 
-**Nothing runs until a runner is registered.** `docker-compose.ci.yml` is the whole
-of that, and its header is the setup checklist: a registration token from
-*Settings → Actions → Runners*, then `make ci-runner`. Gitea itself needs
-`[actions] ENABLED = true` and `DEFAULT_ACTIONS_URL = github` in `app.ini`, the
-second so `actions/checkout@v4` can be resolved.
+**Nothing runs until a docker-mode runner is registered** —
+[`docs/gitea-runner.md`](docs/gitea-runner.md) is the guide, and
+`docker-compose.ci.yml` + `deploy/act-runner.yaml` are the two files it installs.
+Short version, on the runner host:
 
-Two details decide whether the jobs work at all:
+```bash
+mkdir -p /opt/gitea-runner && cd /opt/gitea-runner
+cp …/docker-compose.ci.yml docker-compose.yml && cp …/deploy/act-runner.yaml config.yaml
+printf 'GITEA_RUNNER_REGISTRATION_TOKEN=%s\n' "<token>" > .env && chmod 600 .env
+docker compose up -d
+```
 
-* **The label map.** `runs-on: ubuntu-latest` is pinned to
-  `catthehacker/ubuntu:act-24.04` by the runner's own config, because the jobs need
-  two things from the image: a `node` (Gitea's javascript actions run *inside* the
-  job container) and Python 3.12, which the backend's `requires-python` insists on.
-* **The docker socket**, mounted into job containers so the image can be built. It
-  needs both the mount and `valid_volumes` naming it — see `deploy/act-runner.yaml`.
+`runs-on: ubuntu-latest` means what it means on GitHub: a disposable container,
+here `catthehacker/ubuntu:act-24.04` — chosen because the jobs need a `node` in the
+image (Gitea's javascript actions run *inside* the job container) and Python 3.12,
+which the backend's `requires-python` insists on. A **host-mode** runner answering
+the same label is the one thing that breaks all of this: the job then runs on the
+machine as the runner's user, where `apt-get install` either fails or installs
+packages on your server. The guide covers removing one.
 
 Secrets, all under *Repository → Settings → Actions → Secrets*: