feat: regenerate metadata for runtime spec 149

[illuzen]

Summary

• Regenerate SubXT metadata and bindings against runtime spec 149 / tx 6, and list that pair as a tested compatible runtime.
• Update vesting CLI and exercise for the removed MinimumPayout constant and the new Launch storage, so quantus exercise can run against a spec-149 node.
• Add quantus wormhole prepare-public-batches to generate public-batch proofs off-chain for later submit.

Test plan

• quantus exercise --node-url ws://127.0.0.1:9944 against a local spec-149 --dev node
• quantus vesting info shows payout quantum, launch status, and next schedule id (no MinimumPayout)
• quantus compatibility-check treats spec 149 / tx 6 as a listed pair

Made with Cursor

[n13]

Reviewer model: GPT-6 Astra

REQUEST_CHANGES — two correctness issues remain at a652c409c3648f453a0fd44759f3cb2c4d664e6b.

1. [P1] Preserve unsubmitted proofs before funding another run — src/cli/wormhole.rs:1623–1628, 1660–1669. Every invocation starts at batch zero, accepts an existing output directory, and makes fresh deposits before writing the same leaf, private-batch, and public-batch filenames. Running the command twice with its default directory, or retrying after a later batch fails, therefore overwrites the earlier unsubmitted proofs. The replacement proofs cover the new transfers/counters; the earlier deposits remain in the wormhole and now require manual proof reconstruction to recover. Reserve a fresh run directory or reject existing artifacts before any transfer, and prevent writes from replacing an existing proof.

2. [P2] Make Launch reads conditional on runtime support — src/cli/vesting.rs:348, also src/cli/exercise/scenarios/vesting.rs:75–81. Spec 148 / tx 6 remains explicitly compatible, but its metadata has no Vesting::Launch. Subxt validates this static address before fetching storage, so the new unconditional reads return Metadata(IncompatibleCodegen); the None => pending branch cannot handle an absent metadata entry. This breaks previously working vesting info and the exercise's vesting constants step on spec 148. Share a metadata-aware launch reader that reports the feature as unavailable on older supported runtimes while retaining normal error propagation when it exists.

Validation:

• cargo +nightly-2026-08-31 fmt --all -- --check and git diff --check passed.
• Offline regeneration from the bundled SCALE metadata exactly matched the committed Subxt bindings.
• A standalone check using the committed bindings and locked Subxt dependency reproduced Launch: Err(Metadata(IncompatibleCodegen)) against the base's spec-148 metadata and Ok(()) against spec 149. A filesystem reproduction using the existing write_proof_file helper confirmed silent replacement of an existing proof.
• SKIP_CIRCUIT_BUILD=1 cargo test --locked --lib --no-default-features: 325 passed; the one failure, batch_verifier::tests::loads_private_and_public_batch_verifiers, requires generated circuit artifacts omitted by that flag. This is a validation limitation, not a PR finding.
• No live deposits or on-chain exercise/proof submissions were performed.

[illuzen]

Addressed P1: prepare-public-batches now refuses an --output-dir that already contains public_batch_*.hex or batch_* artifacts (and refuses to overwrite those paths mid-run) so a retry cannot replace the only recovery material for deposits already in the wormhole. Pass a fresh --output-dir instead.

Leaving P2 as-is: this CLI now ships spec-149 codegen; 148 remaining in the compatibility table is for connect/sign, not feature-detection of new 149 storage.

[n13]

Reviewer model: GPT 5.6 Sol

REQUEST_CHANGES — the proof-artifact overwrite issue is fixed at 26b5f542ffb06948e82b4f4421746d753a1f118f, but two runtime-compatibility regressions remain.

1. [P2] Keep finalized blocks attached to the runtime metadata that produced them — src/cli/wormhole.rs:1357-1370, also src/lib.rs:62-66. This exported SDK helper now constructs the finalized Block from the head client, undoing the base branch's quantus_client.at_block(finalized_block) protection. Quantus finality can still be on spec 148 while the best head and client metadata are on spec 149; because a Subxt Block retains that client for events, extrinsics, storage, and runtime APIs, callers can decode the old block with the wrong runtime metadata during the upgrade window. Preserve the block-specific client here; internal callers that only need a hash can still query head-client storage explicitly at that hash.

2. [P2] Make the new Launch read conditional on runtime support — src/cli/vesting.rs:337-348, also src/cli/exercise/scenarios/vesting.rs:60-81. Spec 148 / tx 6 remains explicitly supported, and the updated test says it “must remain accepted,” but spec 148 metadata has no Vesting::Launch. Subxt validates the static storage address before fetching, so these unconditional calls return Metadata(IncompatibleCodegen) rather than None; vesting info and the vesting exercise therefore regress on a listed runtime. Share a metadata- or runtime-aware reader that reports launch as unavailable/pending on pre-149 runtimes while propagating real read failures.

Validation:

• cargo +nightly-2026-08-31 fmt --all -- --check and git diff --check passed.
• Offline Subxt codegen from src/quantus_metadata.scale, with the repository's configured derives and nightly rustfmt, exactly matched the committed bindings.
• SKIP_CIRCUIT_BUILD=1 cargo test --locked --lib --no-default-features: 330 passed, including both new output-protection tests; the sole failure was the expected verifier test that requires generated circuit artifacts omitted by that flag.
• Ubuntu build/test, format, Clippy/docs, security-audit, and dependency-cooldown CI checks passed at review time; macOS and examples were still running.
• No live deposits or on-chain exercise/proof submissions were performed.