[jameskurz-filecoin]

Release jobs repeatedly download identical packages, browser binaries and OS libraries. On October 22 the browser setup alone took 539 seconds; a recent clean release took 7m41s for main CI plus 14m25s for staging and production. Reuse setup inputs while retaining fresh test execution and the existing staged deployment gate.

• Run the two UI shards and demo in the official Playwright image pinned by version and digest; validate it against the installed package and launch Chromium before testing. The database proof uses the host libraries and only installs OS packages for a diagnosed missing-library failure.
• Restore exact-key package downloads, still performing a frozen install with integrity verification. Only main saves the cache; each shard removes its disposable working store, and no test results are cached.
• Reuse environment-scoped container build layers through BuildKit. Public environment configuration stays part of the build key, secrets stay outside the Docker context, and cache export errors do not fail deployment. PR builds read the cache; deployments write it with explicit cache permission behind the existing verified-main trigger gate.
• Record changed workspace filenames when release verification dirties the checkout, so passing tests followed by a failed release have an actionable explanation.

Validation: 40 release-policy tests, targeted lint and formatting, workflow validation with actionlint (its released version predates GitHub’s documented cache-mode key; that exact diagnostic is excluded), image-tag generation, and a real Chromium launch from the pinned container. All nine CI shards, the aggregate release gate, deployment image build, migration-tooling checks and infrastructure checks passed. A feature-branch manual dispatch was correctly refused before either environment ran, confirming GitHub accepts the cache permission while retaining the branch gate. Cold browser environment setup measured 28–43 seconds including container startup, versus the earlier 539-second package-download stall. Package and deployment caches will populate on main; warm-cache deployment timing remains to be measured.