feature: pin the toolchain with varve + the drift check that would have caught meld#390

[avrabe]

jess had no toolchain pin. That stopped being theoretical today.

AFD-045 turned the missing varve pin from a backlog item into a demonstrated defect: jess filed meld#390 against meld 0.41.3 while 0.52.0 was latest — eleven minor versions — and nothing noticed until a stray flag name in findings.yaml gave it away. That cost a supplier's attention on a report whose version citation was wrong.

The measured drift

Three sources decide which binary actually runs. None of them agreed, and nothing ever compared them:

TOOL      PATH          VARVE-PIN     CI-YML        STATUS
rivet     0.32.0        0.34.0        0.25.0        DRIFT     <- three different versions
spar      -             0.40.0        0.24.0        DRIFT
meld      0.41.3        0.52.0        0.41.3        DRIFT
synth     0.49.0        0.58.0        -             DRIFT
loom      1.2.0         1.4.0         -             DRIFT

This sharpens AFD-045's account in a way that matters: CI pins meld 0.41.3 too. So the local machine wasn't drifted from CI — both were drifted from upstream, and CI would not have caught the bad report either. The problem isn't a stale laptop; it's that nothing ever compared the pins to the world.

What lands

file
varve.toml	realm pulseengine, channel rolling, layer 2026.08.4, with digest
varve-realms.toml	fetched from the varve release, not pasted — the rolling root is provisional and rotates at v1.0
tools/varve/check-drift.sh	compares PATH vs varve pin vs ci.yml; exits 1 on disagreement

The digest isn't optional here. Two entries for layer 2026.08.4 exist in this realm under different digests, and varve refuses to guess between them rather than silently picking one. That refusal is the feature. The pinned digest is the one varve install fetched and verified against the realm's trust root.

Verified the newer toolchain actually works

"It installs" is not "it works", so both gates were run under the pinned binaries before recommending them:

• rivet 0.34.0 (vs CI's 0.25.0) → rivet validate → Result: PASS, rc=0
• spar 0.40.0 (vs CI's 0.24.0) → WIT-derivation gate → OK, regenerates wit/ byte-identically

A vacuous row in my own checker, caught and fixed

The first version scored sigil as ok — it's installed nowhere, so the check reported agreement where nothing had been compared. That's the same vacuous-metric failure this campaign keeps hitting, this time in the tool meant to prevent it. Now reported as absent (not checked), with a footer saying such rows aren't evidence.

Negative-controlled: a tool that is present and agrees reports ok with rc=0, so a passing result is reachable and the checker isn't stuck at DRIFT unconditionally.

Honest caveat — the pin is not uniformly newer

The layer carries synth 0.58.0 while the campaign is on 0.60.0 (AFD-042). Adopting it wholesale would downgrade synth.

That's why this PR adds the pin and the check but does not switch ci.yml over. Reconciling CI's env pins with the layer is a separate reviewable change and needs the synth gap resolved first. Until then the pin is authoritative for local work and the drift check makes the disagreement visible instead of silent — which is precisely the control that was missing.

🤖 Generated with Claude Code

https://claude.ai/code/session_017EKh2onUHpWSUiAEqWxfy2