Registry network boundary

All HTTP(S) traffic used to discover or install registry content passes through fetchRegistry / fetchRegistryJson in src/registry/network.ts. The boundary is plain fetch() plus a request timeout, bounded retries on network failure / timeout / 429 / 5xx (honoring a capped Retry-After), a byte cap on the response body, and classified errors: a request that fails after retries, or whose body can't be used, always leaves as an AkmError — never a raw, unclassified exit 70.

• Not found / unusable response (HTTP 404/410, or a body that isn't valid JSON / isn't shaped as expected) -> NotFoundError (exit 1).
• Every other non-2xx status, and connection failure / timeout after retries are exhausted -> TransientError (REGISTRY_UNREACHABLE, exit 75).
• A malformed registry URL, an embedded user:pass@, or a non-http(s) scheme -> ConfigError (REGISTRY_URL_INVALID, exit 78).

Callers: src/registry/providers/static-index.ts, providers/skills-sh.ts, src/registry/resolve.ts (npm and GitHub metadata), src/setup/registry-stash-loader.ts, and src/sources/providers/provider-utils.ts's downloadArchive (npm tarball download, used by sources/providers/npm.ts). Credentials (a resolved GitHub token, etc.) are injected by the caller as ordinary headers on the request — this module does not resolve credentials itself. HTTPS is not required by fetchRegistry itself: --allow-insecure-transport/HTTPS enforcement happens once, where a URL enters configuration (akm registry add, akm bundle add), per AGENTS.md's "Unsafe CLI overrides" policy.

What this boundary does not do

Earlier releases pinned every registry request's DNS resolution: they resolved and classified the hostname's A/AAAA answers, rejected loopback / private / link-local / cloud-metadata / reserved addresses, connected to the one validated numeric address (never re-resolving at connect time), and re-validated on every retry and redirect hop. Because Bun's fetch client cannot pin a TLS connection to a literal address while retaining SNI, that DNS-pinned transport spawned a short-lived Node child process per request to do the actual connect, over a bounded stdin/stdout framing protocol.

That pinning, and the subprocess that implemented it (pinned-transport.ts, pinned-request-helper.ts), were deleted as over-engineering for this codebase's actual threat model: registry URLs are either the built-in registry or a URL an operator explicitly configured (akm registry add, AKM_REGISTRY_URL, AKM_NPM_REGISTRY) — a deliberate human command, not third-party input akm fetches on an untrusted caller's behalf (see AGENTS.md's "Defensive Code" test 3). The subprocess-per-request design was also the direct cause of registry network failures surfacing as an unclassified exit 70 instead of a typed error, a symptom fixed repeatedly before this simplification (see CHANGELOG history around the registry HTTP stack). src/core/network-policy.ts's address classifier is unrelated to this boundary now; it still backs the website source provider's own SSRF guard (src/sources/snapshot-fetchers/host-guard.ts), which fetches arbitrary operator-pasted URLs and keeps its own justification for that guard.

Registry-derived source: git entries are still rejected before an install ref can reach git ls-remote or clone — that check lives in src/registry/providers/static-index.ts and is independent of the network boundary.