feat(infra): reactivate act_runner cache by sharing the runners network

The deferred-since-day-one cache-server gap (documented as
"Cache server (deferred)" in infra/README.md, mentioned every
time we hit a slow CI install). Root cause: act_runner's
built-in cache server binds inside the runner container and
advertises an IP on the compose-defined `apf-portal-act-runners`
bridge — but jobs are spawned via the mounted /var/run/docker.
sock, which puts them on Docker's anonymous default `bridge`
instead. The advertised URL is unreachable from the job, every
cache request burns a ~2 min ETIMEDOUT (restore + save), the
hit rate is zero.

Fix: tell act_runner to attach jobs to the same compose-defined
bridge as the runners, via `container.network` in the shared
runner-config.yaml. The advertised cache URL becomes a normal
internal-network DNS hop, jobs reach the cache server, and
`cache: 'pnpm'` works end-to-end.

The blast-radius trade-off is bounded: every container on the
apf-portal-act-runners network is one of our runner containers
(plus the jobs they spawn), all of which already have full
docker-socket access. Sharing a network does not widen what a
malicious workflow can already do; it just lets jobs reach the
cache server.

Changes:
- infra/runner-config.yaml: add `container.network: apf-portal-
  act-runners`. Surface the `cache.enabled: true` default
  explicitly so a future contributor knows where the toggle is.
- .gitea/workflows/ci.yml: re-enable `cache: 'pnpm'` on every
  actions/setup-node step (5 jobs). Drop the now-stale block
  comment that explained the disablement.
- .gitea/workflows/security-scheduled.yml: same on the two
  setup-node steps in this workflow.
- infra/README.md "Cache server" section rewritten — was
  "(deferred)", now describes the working setup, with the
  rationale and blast-radius note. The disable toggle is
  documented inline.
- ci.yml's Trivy comment trimmed to drop the cross-reference to
  the deferred-cache-server section that no longer exists.

Roll-out on the runner host (manual, post-merge):

    cd <repo>/infra
    git pull
    ./ci-runners.sh rotate

`rotate` recreates the containers with the new
runner-config.yaml mount intact. The first CI job after rollout
seeds the cache from cold (~30-60 s install); subsequent jobs
should report `reused N` instead of `downloaded N` in the
`pnpm install --frozen-lockfile` line and finish a few minutes
faster overall.

infra/README.md

@@ -88,18 +88,15 @@ The compose mounts `/var/run/docker.sock` into each runner so jobs can spawn con
 - **No host filesystem mounts beyond the docker socket:** the compose intentionally does not mount `/`, `/etc`, or any project source. Workflows that need data on the host must do so via Docker volumes.
 - **Future hardening (out of scope of v1):** migrate to **rootless Docker** on the runner host, or to a **DinD (Docker-in-Docker) sidecar** so the runner cannot escape into the host daemon. Decided when the org's RSSI confirms the security posture, or when the runner host is shared with anything else of value.
 
-### Cache server (deferred)
+### Cache server
 
-`act_runner` ships a built-in GitHub-Actions-cache-compatible server, used by `actions/setup-node@v4` (`cache: 'pnpm'`), `actions/cache`, and similar. In the current setup it does **not** work because the runner containers and the job containers live on different Docker networks: the runner is on the compose-defined `apf-portal-act-runners` bridge, while jobs spawned via the mounted `/var/run/docker.sock` come up on Docker's default `bridge` network. The cache server binds inside the runner container on a random port — unreachable from the job. The symptom is a ~2 min `ETIMEDOUT` at the start (restore) and end (save) of every job that opts into caching.
+`act_runner` ships a built-in GitHub-Actions-cache-compatible server, used by `actions/setup-node@v6` (`cache: 'pnpm'`), `actions/cache`, and similar. The default behaviour does **not** work in our compose-based setup: the runner container is on the compose-defined `apf-portal-act-runners` bridge, while jobs spawned through the mounted `/var/run/docker.sock` come up on Docker's anonymous `bridge` network — the cache server binds inside the runner on a random port, advertises an IP on the runners' bridge, and the job can't reach it. The symptom is a ~2 min `ETIMEDOUT` at the start (restore) and end (save) of every job that opts into caching.
 
-For now `cache: 'pnpm'` is left **disabled** in `.gitea/workflows/ci.yml`. `pnpm install --frozen-lockfile` is fast enough on a warm pnpm store inside the job image (~30–60 s cold) that the cache layer adds no value as long as it doesn't actually transfer anything.
+The fix is in [`runner-config.yaml`](runner-config.yaml): `container.network: apf-portal-act-runners` instructs `act_runner` to attach every job container to the same compose-defined bridge as the runners. Job → runner is now an internal-network DNS hop, the advertised cache URL is reachable, and `cache: 'pnpm'` works end-to-end. The `cache: 'pnpm'` flag is enabled on every `actions/setup-node` step in `.gitea/workflows/ci.yml` and `.gitea/workflows/security-scheduled.yml`.
 
-When this is reactivated, the right fix is one of:
+The blast-radius trade-off is bounded: every container on `apf-portal-act-runners` is one of our runner containers (plus the jobs they spawn), all of which already have full docker-socket access. Sharing a network does not widen what a malicious workflow can already do; it just lets jobs reach the cache server.
 
-- attach jobs to the same Docker network as the runners (`runner.container.network` in act_runner's `config.yaml`, then advertise the cache `host` on the bridge IP); or
-- bind act_runner's cache server on a fixed `host_port` reachable from any container (host gateway IP), and set `ACTIONS_CACHE_URL` accordingly.
-
-Either path needs a single-runner spike before being rolled out to the three.
+If the cache ever needs to be disabled (debugging cache-hit issues, etc.), set `cache.enabled: false` in `runner-config.yaml` and `./ci-runners.sh rotate`.
 
 ### `act_runner` image pinning