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

## Summary

Closes the deferred-since-day-one cache-server gap (documented as "Cache server (deferred)" in `infra/README.md` and 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`. 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, `cache: 'pnpm'` works end-to-end.

**Blast-radius trade-off** (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 doesn't widen what a malicious workflow can already do; it just lets jobs reach the cache server.

## What lands

- `infra/runner-config.yaml` — add `container.network: apf-portal-act-runners`. Surface the `cache.enabled: true` default explicitly so the toggle is discoverable.
- `.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.
- `infra/README.md` "Cache server" section rewritten — was `"(deferred)"`, now describes the working setup, rationale, and the disable toggle.
- `ci.yml`'s Trivy comment trimmed to drop the cross-reference to the deferred-cache-server section that no longer exists.

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

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

`rotate` recreates the containers with the new `runner-config.yaml` mount intact (rolling restart, ~15 s pause between each runner so the CI pipeline stays online).

## Test plan

- [ ] CI green on this PR (the gates run on the runners as configured **before** rollout, so this PR's run is one last "uncached" cycle).
- [ ] After rollout, the next CI run's `Set up Node.js` step shows the cache restore attempt **succeed quickly** (no ETIMEDOUT). The `Run pnpm install --frozen-lockfile` step on the first post-rollout run still reports `Progress: resolved N, reused 0, downloaded N` (cold seed).
- [ ] The **second** post-rollout run reports `reused N, downloaded 0` (or a small downloaded delta if Renovate moved a dep meanwhile) — the cache hit is real.
- [ ] `Complete job` step at the end no longer shows `reserveCache failed: connect ETIMEDOUT` warnings.
- [ ] Wall-clock for a typical PR's CI drops by ~5-10 min (5 jobs × ~30-90 s saved on `pnpm install` + the 2× ~2 min ETIMEDOUTs we used to eat).

---------

Co-authored-by: Julien Gautier <julien.gautier@apf.asso.fr>
Reviewed-on: #82

.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