--wp=beta fails with "Could not unzip file" when no beta/RC is offered (404 body saved and unzipped)

Summary

When no WordPress beta or RC build is currently offered — the window between a final release and the next beta cycle — resolving the version alias beta falls through to a URL that does not exist, and the 404 response body is saved to the download cache and then unzipped, so every run fails with:

Fatal error: Uncaught Exception: Could not unzip file. Error code: 19. File size: 18 bytes. in /internal/eval.php:22

This has affected every --wp=beta run since WordPress 7.1 went final on 2026-08-19 (the 7.1 betas/RCs disappeared from the offers). Reproduced on @wp-playground/cli 3.1.47 and confirmed present in 3.1.51 (the resolver code is unchanged).

Steps to reproduce

During a period with no live beta cycle (e.g. now):

rm -f ~/.wordpress-playground/beta.zip   # a previously cached 404 body reproduces it instantly
npx @wp-playground/cli@3.1.51 server --wp=beta

What happens

resolveWordPressRelease('beta') (packages/playground/wordpress/src/wordpress-releases.ts) fetches https://api.wordpress.org/core/version-check/1.7/?channel=beta, filters offers to response === 'autoupdate', and looks for a version containing beta or RC. When none matches, the loop falls through to the generic fallback:

return {
    releaseUrl: `https://wordpress.org/wordpress-${version}.zip`, // → wordpress-beta.zip
    version,   // "beta"
    source: 'inferred',
};

https://wordpress.org/wordpress-beta.zip returns a 404 whose body is the 18-byte text Release not found.. The CLI saves that body as ~/.wordpress-playground/beta.zip and then fails unzipping it (ZipArchive error 19, "not a zip archive"). The poisoned cache file also makes subsequent runs fail the same way without touching the network.

Expected

Two separable fixes, both probably worth doing:

1. Resolver: when beta matches no offer, fall back to the newest stable offer (at that moment the just-released version is what the beta was previewing) — or fail with a clear "no beta is currently offered" error instead of fabricating a URL that never exists for the beta alias.
2. Downloader: never save (or attempt to unzip) a non-OK HTTP response. A status check before writing the cache file would turn this class of failure into an actionable error message and would also stop the cache poisoning.

Environment

• @wp-playground/cli 3.1.47 and 3.1.51, Node 22, macOS 15 and ubuntu-latest (GitHub Actions) — identical failure on both.

Related (checked, distinct)

• #2816 — invalid --wp values silently load latest (validation gap; no crash).
• #2820 — accepts beta through CLI flag validation; doesn't touch the resolver fall-through.
• #2889 — improved the unzip error message; that improved message is the one shown above.

Reproduce the failure with npx @wordpress-playground/cli@3.1.51 server --wp=beta, then read packages/playground/wordpress/src/wordpress-releases.ts and trace resolveWordPressRelease('beta'). Determine which specified behavior should apply when no beta offer exists, and inspect the download path so non-OK responses are neither cached nor unzipped; done means the no-beta case produces the chosen fallback or clear error without cache poisoning.