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/runner-config.yaml

@@ -14,3 +14,22 @@ container:
   # host (see infra/README.md "Updating the runner job images") — not
   # implicitly via :latest.
   force_pull: false
+
+  # Attach every job to the same Docker bridge network as the runner
+  # containers themselves. Default behaviour (no value) is for jobs to
+  # join Docker's anonymous "bridge" network — different from the
+  # compose-defined `apf-portal-act-runners` bridge — which leaves
+  # jobs unable to reach the runner-hosted cache server (the IP it
+  # binds to and advertises is on the runners' bridge, not the jobs').
+  # Sharing the network closes the gap and lets `actions/setup-node`'s
+  # `cache: 'pnpm'` work end-to-end. The blast radius is bounded:
+  # every container on this network is one of our runner containers,
+  # all of which already have full docker-socket access.
+  network: apf-portal-act-runners
+
+# Built-in cache server — defaults are good (enabled, listens on a
+# pseudo-random port, stores cache under the runner's writable home).
+# Documented here only so a future contributor knows where the toggle
+# lives if it has to be disabled.
+cache:
+  enabled: true