fix(nix): repair nix build .#larql (stale cargoPatch, crates.io 403, swagger-ui fetch)

[gburd]

nix build .#larql fails on current main. Three independent causes; each verified in isolation.

1. cargoPatches no longer applies — and is no longer needed

Every hunk of use-system-protoc.patch fails: protobuf-src moved to [target.'cfg(not(windows))'.build-dependencies] and the build.rs files were rewritten into a set_protoc() cfg split.

But the patch also has nothing left to do, because the new build.rs already handles it:

if std::env::var_os("PROTOC").is_none() {
    std::env::set_var("PROTOC", protobuf_src::protoc());
}

package.nix already sets PROTOC, so the bundled protoc is skipped on its own. Dropping cargoPatches is the fix — regenerating the patch would re-add a file to maintain for no behavioural difference. I left the patch file itself in place since nothing references it now; happy to delete it if you'd prefer.

2. Vendoring 403s from crates.io

The pinned nixpkgs (2026-04-18) ships a fetch-cargo-vendor-util whose requests.Session() sends no User-Agent, and crates.io now 403s the default python-requests UA:

curl -A "python-requests/2.32.3" .../base64/0.13.1/download  -> 403
curl -A "Mozilla/5.0"            .../base64/0.13.1/download  -> 200

Current nixpkgs sets one:

session.headers["User-Agent"] = "nixpkgs-fetchCargoVendor/2 (https://github.com/NixOS/nixpkgs)"

So this is a nixpkgs bug rather than a larql one, and the fix is the bump: nixpkgs 2026-04-18 → 2026-09-13. cargoHash refreshed for the vendor tree that results from (1).

Worth flagging how this nearly got misdiagnosed, in case it resurfaces: the failing crate name changes between runs (base64, then ciborium-ll), which reads like parallel-fetch rate limiting. It isn't — --cores 1 -j1 fails identically. And a 2-crate control package vendored fine on my machine, which looked like evidence against the UA theory, until the control turned out to resolve a different fetcher store path (my system's newer nixpkgs, which does set the UA). Same symptom, two nixpkgs, opposite outcomes.

3. utoipa-swagger-ui downloads at build time

Its build script curls the Swagger UI dist tarball, which can't work in the sandbox (no network, and no curl among the build inputs). This hands it a pre-fetched zip via SWAGGER_UI_DOWNLOAD_URL, the env var the crate documents, so it copies dist/ out of a fixed-output derivation.

Verification

All five binaries build: larql, larql-server, larql-router, vindex, vindex3-demo.

• larql-server --version / larql --version run
• Swagger assets are genuinely embedded (strings result/bin/larql-server finds swagger-ui.css, swagger-ui-bundle.js, index.html) — i.e. (3) shipped the UI rather than just silencing the build script

Only nix/package.nix and flake.lock change; no Rust code is touched.

[gburd]

Heads-up on the two red checks (cargo-audit, cargo-deny · advisories) — they are not from this PR.

RUSTSEC-2026-0285 is a rustls advisory published 2026-09-14, a few hours after main's last quality.yml run (23a56db1, 2026-09-14T11:45Z), which is why main still shows green. main's own lockfile pins rustls 0.23.39; the advisory wants >= 0.23.45.

This PR's Cargo.lock is byte-identical to main's:

$ git diff --quiet upstream/main..fix/nix-build -- Cargo.lock && echo IDENTICAL
IDENTICAL

So any PR opened against main right now inherits the same two failures, and a rustls bump is needed on main independently of this change. Happy to add that bump here if you'd like it bundled, but it seemed wrong to fold an unrelated dependency change into a Nix fix.

[gburd]

Follow-up on the two red checks: I've opened #481, which bumps rustls 0.23.39 → 0.23.45 (lockfile only) and clears RUSTSEC-2026-0285.

On that branch cargo-audit and cargo-deny · advisories both pass. Merging it first (or rebasing this branch onto it) turns these two green here as well — they are inherited from main, not introduced by this PR.