fix(edge): serve digest-named GitHub release assets from the registry Worker

[ORESoftware]

registry.zpkg.net answers 503 registry_origin_unavailable ("no independently public fallback was found") for packages that do have a public GitHub Release, so a client cannot reach github.com through the edge while the k8s origin is down.

Cause

zed publish names a packed artifact after its own digest — zpkg-<sha256>.tar.gz. The Worker only matched the conventional names zpkg-<owner>-<repo>-<version>.tar.gz and zpkg-<repo>-<version>.tar.gz, so a real release looked empty to it and the fallback reported nothing public.

Live example, ores-wasm-loaders/owls-interfaces v0.1.1, whose only asset is zpkg-fea1f81d….tar.gz:

$ curl -s https://registry.zpkg.net/v1/packages/ores-wasm-loaders/owls-interfaces/versions/0.1.1
{"ok":false,"error":"registry_origin_unavailable",
 "message":"origin is unavailable and no independently public fallback was found"}   # HTTP 503
$ gh api repos/ores-wasm-loaders/owls-interfaces/releases/tags/v0.1.1 --jq '[.assets[].name]'
["zpkg-fea1f81d31f220bc2c4bdb548546b52e4d7c929e12b64b590143fe75b184ae75.tar.gz"]

zed-cli already accepts this form (release_asset_metadata in src/source_fallback.rs); the edge did not.

Change

• digestFromReleaseAssetName() in workers/shared/github-fallback.js parses the content-addressed name and rejects short, uppercase, or traversal-shaped ones.
• versionFromGithub() accepts a digest-named asset only when no conventionally named asset matches. The digest comes from the name, which is the content address itself, and GitHub's own reported digest must agree with it when present — so a mislabelled asset still fails closed (503), as covered by a test.
• isAllowedPublishedDownload() accepts the same form for sidecar-declared download URLs.

The returned download_url points straight at github.com, so the client fetches bytes from GitHub, bypassing both our origin and R2.

Tests

• workers unit suite: 77 passed (node --test shared/*.test.js api-proxy/src/*.test.js registry-proxy/src/*.test.js cdn-proxy/src/*.test.js org-proxy/src/*.test.js scripts/cf-lease.test.js).
• New: a version read answered from a digest-named asset while the origin returns 503; a digest/name disagreement refused; and helper unit cases.
• scripts/attest-public-github-fallback.mjs: 0 required failures.

Not covered here

cdn.zpkg.net still 404s for /github/<org>/<repo>/<tag>/<name>-<version>.tar.gz, because the byte proxy derives the asset name from the request path and a digest-named asset is not derivable from it without a release lookup. That is a deliberate design point in cdn-proxy (no GitHub API in the byte path), and it no longer blocks installs: the metadata Worker now hands clients the github.com URL directly. Worth a follow-up decision.

Merging this to main triggers deploy-cloudflare-workers.yml.

🤖 Generated with Claude Code