feat: source the TM validator from the chain, and refuse to start without it

[rssh]

What broke

At batch B_5 on 2026-08-20 all three preprod SPOs froze the batch, ran the ceremony, signed TM e86ed19d…, broadcast it to Bitcoin — and then every one of them failed the Cardano post with

cardano.tm_script_cbor not set (from `binocular tm-script`)

The leader cascade worked exactly as designed and walked all three nodes onto the same missing value. The broadcast Bitcoin transaction then sat unconfirmed, which sets in_flight = true, so B_6–B_9 were skipped with "a treasury movement is still in flight". Five batch opportunities lost, with all 8 preflight steps green throughout.

Minting the TM NFT needs the validator itself, not just its hash. heimdall cannot compile it — it is Scalus, it lives in binocular, it is parameterized per bridge instance — so it was an operator-typed CBOR string: the last hand-copied artifact on the posting path, and the only one whose absence was silent. Unset, a node signs a movement it can never post. Mistyped, it mints under a policy nothing scans, discovered on chain after the ceremony is already spent.

What this does

Config #5 names the script and the chain holds it, so the node reads it the way it reads everything else about the bridge.

• bf_http::fetch_script_cbor fetches /scripts/{hash}/cbor and refuses any bytes whose blake2b224(0x03 || cbor) is not the hash they were fetched by. That digest covers the language prefix, so one check proves both the bytes and that they are Plutus V3 — there is nothing left for a provider to get wrong, and nothing an operator has to be trusted to paste.
• cardano.tm_script_cbor joins the retired keys and is refused at load, naming Config docs: FaultProof token-name / ban-policy divergence (technical_questions §5, WI-018) #5.
• New preflight step 9, "post a movement" — the question the rest of the report did not ask. A FAIL stops the node, because a node that cannot post is a node whose turn on the cascade is a wasted hop, and it is invisible from its own log.
• The batch byte budget takes the script's serialised_size from the chain instead of measuring an operator's string, and refuses the batch if it cannot read it. Assuming the script away understates the envelope by ~4 KB — the direction that builds a movement no co-signer reproduces.

A Plutus script is on chain only once something uses it, so the companion change is lantr-io/binocular#32: deploy-script-refs publishes treasury_movement at deployment. Without it the bridge's first movement would need the script in order to make the transaction that would publish it. It is the one entry in that list published for its existence rather than to shrink a transaction.

Deliberately not done

heimdall still passes the script inline (ProvidedScriptSource) and charges its bytes to the envelope, which post_tm_envelope already did correctly — the ticket's "the WI-107 budget may understate the envelope by 4 KB" does not hold. Spending the reference output instead would save ~4 KB per movement and roughly ten more peg-in/peg-out pairs per batch, but whether a node inlines or references changes the byte budget, and a budget that depends on what each node happened to find on chain is a consensus value decided per node. That is a bridge-wide switch, not this change.

Deploying this

The live preprod nodes have tm_script_cbor set by hand (2026-08-21 09:05 UTC, chain-sourced and hash-verified) — this build refuses to load those files. The line must be deleted from /etc/heimdall/spo{1,2,3}.toml before restarting. The script is already on chain for that bridge (past mints put it there), so nothing else is needed there; the binocular change matters for bridges deployed from here on.

Also in this branch

Two commits from the same incident, already running on the preprod nodes: the peg-in scan address in the startup banner and step 3, and show-treasury reporting the treasury's own Y_51 instead of a demo-derived one.

cargo test: 733 lib + all integration green. cargo fmt --check, cargo clippy clean.