feat(boot-test): CI boot tests use the Steam download cache, updated once a day

CI deployed every Steam game from scratch on each run, downloading the whole
game from Steam each time. scripts/boot-test.sh now runs the new
`gbrgames boot-test ID`, the builder's own deploy path: the same payload and
node-agent BootTest, but Steam games start from the cache volume
(gbr-steamcache-<app>, kept by RUNNER.md's prune).

The cache is updated at most once a day (a timestamp in the cache volume, not
copied into servers), so a repeat run within a day doesn't ask Steam for an
update at all; the node-agent's own install still checks the files and fetches
anything newer.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

RUNNER.md

@@ -61,5 +61,13 @@ docker volume prune -af --filter "label!=gbr.cache"
 ```
 
 Not `docker system prune`: it also deletes the `gbr-boottest` network whenever no container is using it,
-and boot tests then refuse to run until `systemctl restart gbr-boottest-network`. Volumes labelled
-`gbr.cache` are the AI builder's Steam download cache.
+and boot tests then refuse to run until `systemctl restart gbr-boottest-network`.
+
+### Steam download cache
+
+Boot tests of Steam games (`installMethod: STEAMCMD`) start from a cached install, one Docker volume per
+app (`gbr-steamcache-<app id>`, label `gbr.cache=steam`), the same cache the AI builder uses. The
+cache is updated at most once a day; the node-agent's own install then only checks the files and
+fetches what changed. So Steam isn't asked for the whole game on every run, which keeps traffic from
+this machine's address low. The prune above keeps these volumes. To drop one game's cache:
+`docker volume rm gbr-steamcache-<app id>`; `STEAM_CACHE=off` turns the cache off.