ci(image): make the workbench asset install resilient to pseudo-dojo.org outages

[sigilmakes]

Problem

The production Workbench image downloads every pseudo-dojo archive from www.pseudo-dojo.org at build time (Dockerfile core-build stage: goldilocks assets install workbench && goldilocks assets verify workbench). No cache, no mirror.

When the runner cannot reach pseudo-dojo.org for ~15 minutes, the build fails. src/goldilocks_core/assets/download.py retries 3× on connect errors, but each attempt blocks the full 300s connect timeout, so one outage window exhausts the retry budget and wastes ~18 minutes before the build dies.

Evidence (PR #218, 2026-09-18 18:14 UTC): requests.exceptions.ConnectTimeout ... 'Connection to www.pseudo-dojo.org timed out. (connect timeout=300)', job burned 20m6s; a rerun of the same commit passed in 4m51s. Scheduled release builds on 09-19 and 09-20 succeeded — the site was reachable, so this is availability, not correctness.

Approach

Pick one (or combine); decide in this issue before implementing.

1. Cache across runs. Give the image build a buildx cache (cache-from/cache-to: type=gha). The assets-install layer survives across builds when its inputs are unchanged, so the download is skipped on cache hits. Cheapest durable option; keeps pseudo-dojo.org as the source of truth.
2. Step-level retry. Wrap assets install workbench in a bounded retry (the whole command, not per-request) so one full outage window no longer fails the build. Cheapest immediate fix; still re-downloads on every cold build.
3. Mirror. Publish the archives to a more reliable host and point src/goldilocks_core/pseudo/registry.toml at it (checksums stay). Most durable; changes the fetch surface for everyone, and needs a licence-aware host (precedent: feat(pseudo): publish the PseudoDojo PBEsol table to PSDI and register it #88 published the PBEsol table to PSDI).

Independent of the choice above: cut the connect timeout. 300s × 4 attempts is the 18-minute burn; a fast-fail timeout (~30–60s) with the existing retries bounds a total outage to a few minutes and makes option 2 viable.

Acceptance criteria

• A CI image build that hits a pseudo-dojo.org outage either succeeds (cache/mirror) or fails within a bounded, documented time
• The chosen approach is recorded in this issue with a short rationale
• just image-e2e passes locally; CI image builds pass

---

Written by an agent on behalf of Willow Sparks.

[sigilmakes]

Willow selected approach 1: GHA layer caching. The workbench quality job will use the pinned Docker Buildx/build-push actions, load the image into Docker, then run the existing end-to-end script without rebuilding it. The cache uses a dedicated workbench-e2e-amd64 scope and mode=max to retain intermediate layers. The release workflow already uses GHA caching and stays unchanged.

This avoids upstream downloads on layer-cache hits only. A cold cache or changes to inputs before the asset-install layer still require upstream access. It does not persist BuildKit cache mounts or guarantee outage-free builds.

Tracking implementation on fix/image-gha-cache. No timeout or mirror changes in this patch.

Written by an agent on behalf of Willow Sparks.