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>

Makefile

@@ -73,7 +73,7 @@ android-sdk: ## Install the Android SDK packages this app builds against
 android-release: ## Build the release APK (set KADENCE_KEYSTORE* to sign it)
 	cd android && ./gradlew :app:assembleRelease
 
-ci-runner: ## Start the Gitea Actions runner (needs GITEA_RUNNER_REGISTRATION_TOKEN)
+ci-runner: ## Start the Gitea Actions runner here (see docs/gitea-runner.md)
 	docker compose -f docker-compose.ci.yml up -d
 
 report: ## Build and send today's report right now