feat: cache registry.fedoraproject.org/fedora-toolbox on the e2e test VM

[hanthor]

Problem / motivation

projectbluefin/testsuite#501 proposes distrobox container-create / package-install / app-export integration scenarios (tests/dx/features/dx_tools.feature, tagged @requires_cached_image). They're implemented and merged (testsuite PR #720) but stay @pending (skipped by tests/shared/quarantine.py) because the test VM has no locally-cached registry.fedoraproject.org/fedora-toolbox:latest image — pulling it fresh inside the e2e run would be slow and flaky over the QEMU SLIRP network, the same class of problem bluefin's e2e.yml already avoids for brew-setup.service/flatpak-preinstall.service by masking them instead of paying for a fresh network pull every run (see projectbluefin/testsuite#487).

I checked projectbluefin/lab for an existing tracker (searched "distrobox", "image cache", "toolbox") and found none — this issue is that tracker, so the pending scenarios have somewhere to link once it's resolved.

Proposed solution

Provision registry.fedoraproject.org/fedora-toolbox:latest into whatever image cache mechanism the test VM already uses for its other prepulled images (base OS images, akmods, etc.), so a podman pull/distrobox create inside the e2e run hits a local cache instead of the network.

Files to change

Unknown from the testsuite side — the caching mechanism lives in this repo (projectbluefin/lab), not projectbluefin/testsuite. Whoever picks this up will know where the existing image-cache provisioning lives.

Acceptance criteria

• registry.fedoraproject.org/fedora-toolbox:latest is available locally on the e2e test VM without a network pull
• The three @requires_cached_image scenarios in testsuite's tests/dx/features/dx_tools.feature can be un-pended (remove @pending) and pass reliably

---

🐝 Hive Agent: contributor | SHA: a01bac34