feat: select the governance track, and decode referenda against live metadata

[n13]

Two changes that together let the CLI drive a runtime upgrade on a chain older than the CLI itself. Found while upgrading Heisenberg (spec 144 → 148); both are exercised by that upgrade, which is in flight on referendum #5.

1. Governance track selector

Runtime upgrades already go through System::authorize_upgrade plus the permissionless apply_authorized_upgrade; only the referendum's proposal origin differs between the fast and slow lanes. That origin was hardcoded:

let origin = Value::unnamed_variant(
    "Origins", [Value::unnamed_variant("FastUpgrade", Vec::<Value>::new())]);

So the CLI could not upgrade a runtime predating the fast_upgrade track — Origins is absent from its metadata, so the payload fails to encode.

--track {fast-upgrade,root} on runtime update, tech-referenda submit, and tech-referenda submit-with-preimage:

track	origin	referenda track	thresholds	timing
fast-upgrade (default)	Origins::FastUpgrade	fast_upgrade	80% / 80%	~30 min
root	system::Root	tech_collective_members	61% / 60%	~2 days

Default is fast-upgrade, so existing usage is unchanged. root works on every runtime, including ones with no Origins enum.

Sunsetting set_code

The exercise suite's real-upgrade scenario used system.set_code. A runtime blob is hundreds of KiB against a 64 KiB MaxProposalSize, so that shape can never be a real proposal — the scenario exercised a path production cannot use. It now authorizes the hash and applies the blob, matching production. UpgradeMode::SetCode → UpgradeMode::Authorize. SelfNoop keeps authorize_upgrade_without_checks, since re-installing identical code would trip SpecVersionNeedsToIncrease.

2. Referenda reads decode against live metadata

referendum_info_for used the generated static types, so ReferendumStatus embedded the codegen's OriginCaller. Against a runtime whose custom-origin pallets differ, every read failed:

❌ Failed to fetch referendum #5: Metadata(IncompatibleCodegen)

list, get, and status were all unusable against Heisenberg from a CLI built for 148 — while submitting worked fine, because that path encodes dynamically. The upgrade could be started but not monitored.

ReferendumInfoFor is now read through subxt's dynamic storage API, with the displayed fields pulled out by name into a small ReferendumSnapshot. Works on any runtime still using upstream pallet-referenda field names; display output is unchanged.

Enactment projection

While a referendum is Preparing, the status command said enactment was unavailable. But once the decision deposit is placed and the proposal is not queued, every remaining phase length is known, so the earliest possible enactment is computable — and it is the block operators actually wait for before runtime apply:

🏁 Enactment estimate: unavailable until the prepare period ends and Deciding starts
   ⤷ projected, if the current tally still clears the threshold when Deciding opens:
     - Confirm ends at block 969790 (in 7732 blocks / ~25.8h, ≈ 2026-09-02 18:13 UTC)
     - Enactment at block 976990 (in 14932 blocks / ~2.1 days, ≈ 2026-09-03 18:13 UTC)

Cold wallets

Unaffected. The track only changes which payload is built; submit_transaction dispatches WalletSigner::Hot/Cold internally, so Keystone/QR signing works on both tracks.

Verification

Against live Heisenberg (spec 144) with a CLI built for 148:

• runtime update --track root submitted referendum some cleanup, added list pending transactions #5; raw storage confirms origin bytes 00 00 = system::Root on track 0, proposal Lookup len 34, preimage = System.authorize_upgrade(0x58b93c5f…84ec) = blake2-256 of quantus-runtime-v148.compact.compressed.wasm
• tech-referenda status --index 5 now renders fully where it previously returned IncompatibleCodegen
• 316 unit tests pass (2 new, covering both origins and the default); cargo clippy --release --all-targets clean; cargo +nightly fmt --all -- --check clean

Follow-up

Other commands may still decode against bundled codegen rather than live metadata; that survey is deliberately not in this PR and will follow separately.

[n13]

Reviewer model: GPT Sol

Verdict (advisory): Request changes

Blocking finding:

• src/cli/tech_referenda.rs:729 — The new .map_err(Into::into) converts QuantusError to the same type. The repository's required SKIP_CIRCUIT_BUILD=1 cargo clippy --all-targets --locked -- -D warnings command rejects it as clippy::useless_conversion, so the analysis check fails and its documentation steps never run. Remove the no-op conversion and return referendum_value::decode(&value).map(Some) directly, then rerun the strict analysis job.

Validation at exact head 7b200e23a375aed2b94166ba66251b5015d0f722:

• cargo test --locked: 316 library tests and 314 binary tests passed; one doc test ignored.
• cargo +nightly-2026-08-31 fmt --all -- --check and git diff --check: passed.
• quantus runtime update --help: exposes --track {fast-upgrade,root} and preserves fast-upgrade as the default.
• Live read-only tech-referenda status --index 5 against Heisenberg successfully decoded the older-runtime referendum and rendered its track, tally, phase, and projected enactment.
• Hosted Ubuntu build, format, dependency-cooldown, and security checks pass; macOS/examples remain in progress at review time. Strict Clippy fails locally and in CI at the line above.

I found no other blocking issue in the four-file diff, but the required analysis gate must be restored before merge.