fix(nix): point fetchCrate at static.crates.io too

[dlipicar]

Third and last fetcher on the 403 endpoint, closing out #9 / #10 / #11 and the consumer
wiring in logos-co/logos-module-builder#233 and logos-co/logos-rust-sdk#56.

Why this one was missed

fetchCrate pulls a crate's own source tarball, not a vendored dependency, so
neither sibling overlay touches it — one adds a User-Agent to fetchCargoVendor, the
other rewrites importCargoLock's URLs.

#9 left it alone on the grounds that "nothing here fetches through it". True of this
repo; false of a module closure, which reaches rav1e and cargo-c via
qtdeclarative → qtsvg → jasper → libheif. Measured live with substituters disabled, on
the rav1e source derivation:

URL	result
crates.io/api/v1/...	curl (22) 403 → cannot download rav1e-0.8.1.tar.gz from any mirror
static.crates.io/...	builds, and lands on the same store path 0s8jm042…-rav1e-0.8.1.tar.gz

The change

Swaps registryDl — fetchCrate's own documented argument — rather than
re-instantiating the file. A caller naming a registry still wins, and the value is the
one upstream itself moved to: NixOS/nixpkgs#524979 spells
registryDl ? "https://static.crates.io/crates" at b5aa0fbd. Identity on a pin that
already points at the CDN; evaluation-time failure if the pin references neither prefix.

#9's stated objection, measured

#9 skipped this because overriding fetchCrate "moved the devShell drvPaths on every
system". That reproduces and is real — but it is cosmetic:

	drvPath	outPath
devShell aarch64-darwin	ki8lzz89 → pjar0vgb	l9hpbrxa… unchanged
devShell x86_64-linux	f9yh59sr → x2nb5rjz	lsjg4sw0… unchanged

Same for the packages that actually fetch this way: rav1e, its source FOD and
cargo-c all keep their exact outPaths. Nothing rebuilds; only .drv files differ.

Gate

checks.<sys>.fetch-crate-overlay asserts the rewrite for real, in the style of the
sibling gate — it calls fetchCrate with unpack = false so the probe is a plain
fetchurl exposing urls, and fails if the CDN prefix is absent or an API URL survives.
Verified non-vacuous by neutering the overlay to args: prev.fetchCrate args:

error: fetch-crate overlay drift: crate source not on the CDN
       (https://crates.io/api/v1/crates/logos-gate-probe/0.0.0/download)

The mutation suite gains M7 for the same property and is 8/8;
nix flake check --no-build --all-systems exits 0.

checks.<sys>.overlay-exports needed no change — registering the overlay in both
nativeOverlays and lib.overlays kept it at 3 == 3, which is exactly what that gate is
for.

After this

All three crate fetchers are on the CDN, and consumers pick this up through
lib.nativeOverlays with no change on their side. Remaining known item, unrelated to
this PR: logos-workspace/flake.nix:25 still pins logos-nix at 6e0f4a71, so bumping
logos-module-builder past #233 there without bumping logos-nix in the same commit makes
ws build throw a crates.io error on C++ repos.

🤖 Generated with Claude Code