swarm-ci-runner: keep the registration token on the host's /run, not in the container's root

swarm-bao-ci-runner still reads the token from bao under the runner's own
ci-runner leaf, but now writes it to /run/swarm-ci-runner on the host
(tmpfs), which the container bind-mounts read-only for the register
unit's LoadCredential. Before, it wrote the token to
/var/lib/nixos-containers/swarm-ci-runner/var/lib/swarm-ci-runner/registration-token
on persistent disk, where a superseded token stayed after rotation and
went into backups of the container root. The container's tmpfiles now
remove that old file.

Rotation is unchanged: the ten-minute timer rewrites the file when the
value differs and refresh_consumer restarts the runner. After a reboot
the token is fetched again; until the store answers, a runner that is
already registered keeps running and only a new registration waits.

Part of #4998 (slice 1).

docs/scheduler/ci.md

@@ -159,8 +159,11 @@ needs `deploy.forgejo.enable` or a hive on its host.
 2. **`swarm-bao-ci-runner.service`** on the runner's host logs in to the store
    with the `ci-runner` leaf, whose `swarm-ci-runner` role reads that one path
    and nothing else, retrying every 30 seconds until the token is there. It
-   writes the token to a root-only file inside the container, and restarts
-   the runner when the value changes. It runs at boot, on deploy, and every
+   writes the token to a root-only file in `/run/swarm-ci-runner` on the host,
+   which the container sees read-only, and restarts the runner when the value
+   changes. `/run` is tmpfs, so no copy reaches persistent disk; after a reboot
+   the unit fetches the token again, and until the store answers only a
+   runner that has no `.runner` yet waits. It runs at boot, on deploy, and every
    ten minutes on a timer.
 3. **`swarm-ci-runner-register.service`** in the container is the only unit
    that loads that file, with `LoadCredential=`. systemd hands a unit's