chore(infra): pin act_runner image pull policy

`act_runner`'s default `container.force_pull: true` re-issues a
`docker pull` at the start of every job, adding 10-30 s of registry
round-trip per job even when every layer is already locally cached.
The job images are already pinned to specific tags (catthehacker
ubuntu :act-22.04 + :full-22.04), so the implicit pull is both pure
overhead and contradictory with the deliberate-upgrade policy
ADR-0015 spells out for the runner image itself.

Mount a shared `infra/runner-config.yaml` into all three runners
with `force_pull: false`, point each runner at it via the
`CONFIG_FILE` env var, and document the pre-pull procedure (one-shot
`docker pull` on the runner host, plus the upgrade playbook) in
infra/README.md "Job image pinning and pre-pull".

The pre-pull is also folded into the "First-time registration"
walkthrough so a fresh setup is correct end-to-end.

infra/runner-config.yaml

@@ -0,0 +1,16 @@
+# act_runner config — shared by all three runner instances defined
+# in ci-runners.compose.yml. Mounted read-only at /etc/runner/config.yaml
+# inside each container, selected via the CONFIG_FILE environment variable.
+#
+# Generated from `act_runner generate-config` and trimmed to the keys we
+# actually need to override. Defaults for everything else.
+# See: https://gitea.com/gitea/act_runner/src/branch/main/internal/pkg/config/config.example.yaml
+
+container:
+  # Skip the per-job `docker pull` round-trip when the image is already
+  # cached locally. The default (true) re-checks the registry on every
+  # job start, adding 10-30s of latency per job for no value once the
+  # tag is pinned. Image upgrades happen deliberately on the runner
+  # host (see infra/README.md "Updating the runner job images") — not
+  # implicitly via :latest.
+  force_pull: false