fix(nix): apply logos-nix's native overlays in mkPkgsWith

[dlipicar]

The consumer line for logos-co/logos-nix#9, #10 and #11. Supersedes #220 — see the
comment there.

The problem

mkPkgsWith (lib/common.nix) was a bare
import nixpkgs { inherit system; overlays = extraOverlays; }, so every module's
package set missed logos-nix's crates.io fixes. crates.io's /api/v1/crates/*/download
returns 403 to any User-Agent starting curl/ — exactly what nixpkgs' fetchurl
sends — so a Rust module 403s on every crate the org cache misses.

mkLogosModule vendors with cargoLock (lib/mkLogosModule.nix:586), i.e. through
importCargoLock, not fetchCargoVendor. #220 wires only the UA overlay, which
fixes the other fetcher; it is not the one module crates go through.

The change

Take logos-nix's lib.nativeOverlays list rather than naming entries. Naming them is
exactly how the importCargoLock fix reached master applying to nothing, and a third
overlay would repeat it. The logos-nix pin moves to master for that export — nixpkgs
stays at e9f00bd8 and the lock keeps all 756 nodes, so nothing else in the closure
shifts.

An old logos-nix throws rather than silently applying nothing:

logos-module-builder: the pinned logos-nix predates lib.nativeOverlays, so Rust
modules would vendor crates from an endpoint crates.io 403s. Bump the logos-nix
input past logos-co/logos-nix#11.

#220's lib.optional (logos-nix ? lib.overlays.X) shape degrades to a no-op on a stale
pin and re-opens the 403 with no diagnostic — the exact failure mode this chain exists
to close. logos-nix == null still yields [ ] and is unaffected.

Measured

On checks.aarch64-darwin.rust-native-dep, reading urls off the crate FODs in the
realised closure (not an eval-level guess):

	crate fetches	endpoint
before	15	all https://crates.io/api/v1/crates
after	12	moved to https://static.crates.io/crates

The UA overlay arrives too — fetch-cargo-vendor-util-ua appears in the closure.

Merge order — this needs a coupled workspace bump

The new throw is reachable by the primary consumer. logos-workspace/flake.nix:25 pins
logos-nix at 6e0f4a71 and 32 inputs.logos-nix.follows lines force every repo,
including this builder, onto that pin. Measured in the workspace:

nix eval .#logos-capability-module.drvPath --override-input logos-module-builder path:<this branch>
  -> logos-module-builder: the pinned logos-nix predates lib.nativeOverlays ...

That is a C++ module, and .#logos-liblogos throws the same way — the workspace's
allPkgs fold is strict, so a stale pin surfaces as a crates.io error on repos that
have nothing to do with Rust.

No immediate breakage on merge: the workspace currently pins this builder at e234a4c6,
before this change. But whoever next bumps logos-module-builder past this commit must
bump logos-nix past logos-co/logos-nix#11 in the same change, and anyone running
ws build --auto-local against a local checkout of this branch hits it today. The
alternative — degrading to [] on a stale pin — is the fail-open shape that let this bug
live for weeks, so the throw stays and the message names the fix.

This is necessary but NOT sufficient

Two further holes, neither reachable from here.

1. logos-rust-sdk. The other 11 crate fetches in this subject's closure belong to
logos-lidl-gen, built by logos-rust-sdk from its own bare import nixpkgs. It needs
two edits, not one — flake.nix:69 for the package outputs and flake.nix:196,
which the sdk-unit-tests check resolves against; fixing only :69 leaves that check
vendoring through the 403 endpoint. Currently latent rather than fatal: all 11 are
substitutable from cache.nixos.org today, so a green run proves the cache is warm, not
that the fetch works.

2. A third fetcher neither overlay covers. fetchCrate still points at the API
endpoint — logos-co/logos-nix#9 left it there deliberately, on the grounds that nothing
fetched through it. That is not true of a module closure: rav1e and cargo-c arrive as
fetchCrate source tarballs via qtdeclarative -> qtsvg -> jasper -> libheif, and
https://crates.io/api/v1/crates/rav1e/0.8.1/download returns 403 today to the
User-Agent nixpkgs' fetchurl sends. Same latency caveat: cached today, fatal on a cold
store.

So: do not read a green run here as "Rust module builds are fixed".

Blast radius

The only derivations this change touches are fixed-output ones — the crate tarballs
and the *-vendor-staging FODs — plus one new fetch-cargo-vendor-util-ua helper.
46 of 1284 derivations differ and every root is a FOD, so hashDerivationModulo
absorbs them and none propagates downstream.

Module output paths do move, but for an unrelated, pre-existing reason:
LOGOS_MODULE_BUILDER_ROOT embeds the builder's own source path, so any commit here
moves every module. Two independent proofs: appending a single no-op comment to
lib/common.nix on master moves them exactly the same way, and an isolation run holding
the builder source fixed while neutering the overlays (--override-input logos-module-builder/logos-nix at a copy with nativeOverlays = [ ]) reproduces the
identical module and .lgx outPaths. The overlays move zero outputs.

Also verified end to end, substituters disabled: the pre-change crate derivation dies on
curl (22) ... 403, the post-change one builds — and both land on the same store path.
The custom-toolchain path works too: logos-chat-module (nix.rust.toolchain 1.95.0, 11
git deps) moves all 561 of its crates to the CDN with no throw.

🤖 Generated with Claude Code

[github-actions]

📊 Doc-test reports

The four ways to wrap a C library plus the two cross-language composition tours — each scaffolded into real modules, built against this commit, loaded in logoscore, and driven — rendered alongside the commands actually run and their output (updated each run, commit 0d53a68):

• ubuntu-latest report
• macos-latest report

Pages can take a minute to update after the run finishes.