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.

.gitea/workflows/ci.yml

@@ -2,15 +2,6 @@
 # Thin YAML — orchestration lives in package.json scripts (ci:check,
 # ci:audit, ci:commits, ci:perf) and Nx targets. Any change to gate
 # behaviour belongs in those scripts, not in this file.
-#
-# `cache: 'pnpm'` is intentionally NOT enabled on actions/setup-node
-# below: act_runner's built-in GitHub-Actions-cache server is bound on
-# the runner container and is unreachable from job containers (which
-# run on Docker's default network, not the runners' compose network).
-# Each request burns a ~2 min ETIMEDOUT on restore + another on save,
-# for zero hit rate. Once the runner network/cache config is fixed
-# (tracked in infra/README.md "Cache server"), re-add `cache: 'pnpm'`
-# here.
 
 name: CI
 
@@ -50,6 +41,7 @@ jobs:
       - uses: actions/setup-node@v6
         with:
           node-version-file: '.nvmrc'
+          cache: 'pnpm'
       - run: pnpm install --frozen-lockfile
       - run: pnpm ci:check
 
@@ -71,14 +63,13 @@ jobs:
       - uses: actions/setup-node@v6
         with:
           node-version-file: '.nvmrc'
+          cache: 'pnpm'
       # Dependency vulnerability scan. Trivy is a Go binary, not an npm
       # package, so it cannot live in package.json scripts as cleanly
       # as audit/lint do.
       #
       # We deliberately avoid `aquasecurity/trivy-action`. On cache
-      # miss (our act_runner cache server is unreachable from job
-      # containers — see infra/README.md "Cache server (deferred)"),
-      # the action falls back to `git clone github.com/aquasecurity/
+      # miss the action falls back to `git clone github.com/aquasecurity/
       # trivy` to fetch its install script, using `actions/checkout`
       # which defaults `with.token` to `${{ github.token }}` (Gitea's
       # auto-token, useless for github.com). The clone hits the
@@ -171,6 +162,7 @@ jobs:
       - uses: actions/setup-node@v6
         with:
           node-version-file: '.nvmrc'
+          cache: 'pnpm'
       - run: pnpm install --frozen-lockfile
       - run: COMMIT_LINT_FROM=origin/main pnpm ci:commits
 
@@ -195,6 +187,7 @@ jobs:
       - uses: actions/setup-node@v6
         with:
           node-version-file: '.nvmrc'
+          cache: 'pnpm'
       - run: pnpm install --frozen-lockfile
       - run: pnpm ci:perf
       - uses: actions/upload-artifact@v7
@@ -212,6 +205,7 @@ jobs:
       - uses: actions/setup-node@v6
         with:
           node-version-file: '.nvmrc'
+          cache: 'pnpm'
       - run: pnpm install --frozen-lockfile
       # Placeholder until the e2e a11y suite (axe-core via Playwright,
       # per ADR-0016) is wired with the first real screens. The job

.gitea/workflows/security-scheduled.yml

@@ -33,6 +33,7 @@ jobs:
       - uses: actions/setup-node@v6
         with:
           node-version-file: '.nvmrc'
+          cache: 'pnpm'
       # Full-tree Trivy (no skip-dirs, no severity filter — the per-PR
       # gate filters by severity for speed; this run wants the full
       # surface for the security feed). Manual install + curl, same
@@ -92,6 +93,7 @@ jobs:
       - uses: actions/setup-node@v6
         with:
           node-version-file: '.nvmrc'
+          cache: 'pnpm'
       - run: pnpm install --frozen-lockfile
       - run: pnpm exec lhci collect --url=${{ vars.LHCI_PROD_URL }} --numberOfRuns=3
       - run: pnpm exec lhci assert --config=./lighthouserc.js