Module fetch 

Release resolution, streamed download, and atomic cache-verify for third-party .modl module artifacts (Phase 15, RMOD-02/03).

ModuleFeed talks to a module’s GitHub release feed over a SEPARATE reqwest::Client from crate::client::ReqwestGatewayApi (D-03): the gateway client suppresses ALL redirects for the uncommissioned-gateway wizard 302 (see crate::client::build_client’s redirect policy), which would swallow the mandatory release-CDN redirect this fetch depends on. Redirects here are left at reqwest’s untouched default (follows up to 10 hops).

ModuleFeed::fetch_and_verify resolves ONLY through the tag-pinned releases endpoint (/repos/{repo}/releases/tags/{tag}) — the floating releases/latest endpoint is never called, for any reason, including as a fallback (SC-1). A cache hit (super::cached_entry, keyed by version alone) short-circuits before any request is built, which is what makes SC-3 (no network on a repeat fetch) and SC-4 (offline-with-cache succeeds) possible.

Structs

FetchedModule

The result of a successful ModuleFeed::fetch_and_verify call — core returns models, never prints (Phase 16’s --json renders this).

ModuleFeed

A third-party module release feed — one reqwest::Client, kept SEPARATE from crate::client::ReqwestGatewayApi (D-03).

Enums

ArtifactSource

Where a FetchedModule’s bytes came from.

FetchPolicy

How a fetch treats an existing cache hit (D-02, D-09). All three behave IDENTICALLY on a cache MISS — the miss path (resolve, download, verify, persist) is implemented exactly once and is reached by every policy alike.