feat: labs repo downloads aztec toolchain

[fcarreiro]

Implements the labs-repo side of labs-aztec-toolchain: instead of linking locally built binaries, build_labs provisions the pinned toolchain from releases. Follows #25047 (merged). With the Makefile dependency on noir bb-cpp-native commented out, the monorepo takes the same downloaded toolchain, so build_monorepo is now unused — kept in case the foundation side wants it.

Closes https://linear.app/aztec-labs/issue/A-1532/source-bbnargo-from-an-aztec-toolchain-directory-for-labs .

Provisioning (build_labs)

Pins at the top of the script: BB_VERSION=6.0.0-nightly.20260729 and NOIR_VERSION=1.0.0-beta.25. Every source URL is env-overridable (BBUP_URL, NOIRUP_URL, BB_AVM_URLS, NOIR_SOURCE_URL) for testing and mirroring, and NOIR_TAG covers noir's two tag shapes (v<semver> for releases, unprefixed for nightlies).

• bb via bbup, curled from next at build time and run with BB_PATH=<toolchain bin> + --no-modify-path.
• nargo + noir-profiler via noirup, curled from noir-lang/noirup main and run with an isolated NARGO_HOME (noir releases ship the profiler next to nargo; no shell config or ~/.nargo is touched).
• bb-avm straight from the release: bbup's artifact name is hardcoded to the plain bb, so this fetches barretenberg-avm-amd64-linux.tar.gz itself, barretenberg mirror first and aztec-packages as fallback, matching bbup's order. It is published for amd64 linux only, so elsewhere it is skipped rather than fatal — its consumers (AVM proving) only run there anyway.
• acvm compiled from the noir release source tarball, because nothing publishes it: no noir release asset, and acvm_cli is not on crates.io.

Every path cargo writes to lives under the run's mktemp -d and dies with it — CARGO_HOME (so the fetched crates stay out of the user's registry cache), CARGO_TARGET_DIR, the --root install prefix, and the extracted source. Three details behind that:

• Cargo runs from inside the source tree so rustup picks up noir's rust-toolchain.toml. From anywhere else the ambient cargo is used, and a cargo older than noir's MSRV fails the build (hit for real with a 1.85 on PATH).
• RUSTFLAGS remaps the temp paths out of the binary. Left in, the mktemp name lands in the executable and every build of the same source produces different bytes, which would poison the pin hash and every downstream cache key derived from bootstrap.sh hash.
• GIT_COMMIT/GIT_DIRTY are passed in because noirc_driver's build script reads them from a git checkout, and a release tarball is not one.

A build from scratch is ~5 minutes (~1.5 compiling, the rest fetching ~330 dependency crates that the isolated CARGO_HOME discards), so the built binary goes through the ci3 build cache under labs-acvm-<noir version>-<platform>. The key carries the platform explicitly since, unlike keys derived from cache_content_hash, it is otherwise just a version.

Pin record and per-binary staleness

bin/.pin records the pinned versions and a git hash-object content hash per binary, written only for those present — so an optional binary's absence is part of the record too. is_current <binary> <release key> <version> then answers for one binary: it exists, the recorded release matches the pin, and the recorded hash matches the actual contents. Matching versions alone would not catch a corrupted or swapped binary.

Checks are per binary, feeding install flows that are coarser: bbup and noirup each provision a whole release in one shot, while bb-avm and acvm are provisioned individually. A corrupt nargo therefore re-runs only noirup; a missing bb-avm re-downloads only its artifact. Where a binary cannot be provisioned on the machine (bb-avm off amd64 linux, acvm with no cargo), drop_unprovisionable removes whatever sits in its place, so the record never attests contents from a different provisioning. Each install rm -fs its destination first: unpacking or copying onto a leftover symlink writes through it, into the linked build output.

The record is written once before the acvm build and again at the end, so a failed source build does not cost the downloads that already succeeded; a stale acvm is dropped before that first write so an interrupted run cannot leave the record attesting contents that are about to be replaced.

noir_version reads only the pin record: the binary reports its base cargo version, which cannot distinguish a nightly from the release it was cut from. hash covers the three required binaries plus bb-avm/acvm when present — what the toolchain provides, including their absence, is part of its identity.

bbup

install_bb runs bbup with --no-modify-path, which is not part of this PR: that flag and the idempotent update_shell_config go in through #25060 against next. Until it lands, build_labs with the default BBUP_URL fails on the unknown flag (tested here via a file:// override); once it does, BBUP_URL can pin that commit instead of tracking next.

Docs

labs-aztec-toolchain/README.md describes what the component provisions and what consumers read from it; root CLAUDE.md now states the $NARGO default per side (fnd/** submodule build, labs/** toolchain); noir-projects/labs/contract-snapshots/README.md no longer points at the submodule build.

Testing

Real downloads and builds:

• bb-avm fetched from the release (147 MB), bb-avm --version → 6.0.0-nightly.20260729.
• acvm built three times in fresh temp dirs → byte-identical every time (git hash-object 458823a1…), acvm version = 0.40.0. Afterwards: temp dir gone, no ~/.cargo/bin/acvm, and the user's registry cache entry count unchanged.
• Cache round trip via CACHE_LOCAL_DIR: miss → build → upload (12 MB → 4.4 MB), then hit → restored with its exec bit in 0.26s instead of ~5 min, pin recording the restored hash.

Staleness scenarios, with stand-in installers so no release traffic was involved:

• cold install; no-op rerun; corrupt nargo → only noirup; missing bb → only bbup; missing noir-profiler → only noirup.
• simulated non-amd64 (setarch linux32) → bb-avm skipped and dropped; no cargo on PATH → acvm skipped, dropped, and its hash absent from the record.
• failed source download mid-build → record stays honest (no acvm_hash, corrupt file removed) and the next run retries only acvm, without re-downloading bb or nargo.
• monorepo-style symlinks in bin/ taken over by downloads with all five pretend build outputs left byte-identical.

Notes

• On a cache miss the acvm build is ~5 minutes, and ci3 only uploads from CI, so the first person to build a newly pinned noir version pays it locally.
• The pin record attests contents from install time onward; it does not validate a fresh download against a known-good checksum. If we ever want that, the script would need to carry expected per-platform hashes.