Add quantus exercise chain smoke/fuzz suite

[illuzen]

@ -0,0 +1,53 @@

feat: add quantus exercise chain smoke/fuzz suite

Summary

Adds a single command — quantus exercise — that runs a scenario-based smoke and fuzz suite against a live node, covering every call path the CLI wraps. It is designed as a pre-runtime-upgrade regression gate: run it before and after an upgrade and any extrinsic that stops working (or any validation that silently loosens) fails the suite with a nonzero exit code, making it CI-ready.

quantus exercise                              # default phases against ws://127.0.0.1:9944
quantus exercise --json --fuzz-iterations 25  # CI mode
quantus exercise --upgrade-wasm runtime.wasm  # full governance upgrade + post-upgrade re-run

What it covers

Phase	Scenarios
setup	connect, compatibility check, dev wallets, derive + fund ephemeral accounts
reads	runtime version, metadata pallets, chain properties, blocks/events decode, treasury, high-security status, scheduler storage, balances
balances	single transfer, Utility::batch, transfer with tip, manual nonce, remark_with_event
reversible	schedule + owner-cancel (one-time delay), schedule with delay, set_high_security + HS default-delay transfer + guardian cancel
multisig	2-of-3 lifecycle: create, fund, propose, approve, execute, verify recipient balance
recovery	config reads; initiate_recovery pinned as clean NotRecoverable (CLI lacks create_recovery — documented limitation)
preimage	note_preimage + status verify; request_preimage pinned as BadOrigin
governance	membership reads, full TechReferenda flow (submit, decision deposit, 3 aye votes), add_member pinned as BadOrigin
negative	over-balance, below-ED, overflow amount, malformed SS58 (client-side), stale nonce, delay-too-short, self-guardian, default-delay-without-HS, scheduler-calls-disabled canary, removed-pallets canary
fuzz	seeded loop of random transfers / remarks / batches / reversible delays with boundary amounts (0, 1, ED±1, u128::MAX); every iteration must succeed cleanly or reject cleanly
wormhole	multiround flow (5 rounds, 5 proofs each); included by default — proving is fast on release builds. Use --skip wormhole on debug builds
upgrade (opt-in)	note WASM preimage, System::set_code via TechReferenda on a fast-governance node, poll for spec bump, then automatically re-run all phases against the upgraded runtime

Negative scenarios assert the specific expected error, so a runtime upgrade that accidentally loosens validation is caught, not just crashes.

Flags

--phases / --skip, --fuzz-iterations N (default 25), --seed <u64> (reproducible fuzzing; seed is always printed), --upgrade-wasm <path>, --upgrade-timeout-secs, --ephemeral-accounts N, --fail-fast, --json.

Also in this PR

• Metadata regenerated for spec 134 (was 131): community Referenda/ConvictionVoting pallets removed, Scheduler dispatchables disabled. The stale referenda CLI modules and scheduler dispatch code are removed accordingly; compatibility table updated.
• Quiet logging mode (src/log.rs): the exercise suite suppresses per-transaction chatter (spinners, expected-failure error banners) so the per-step report is the single source of truth. --verbose restores full output. Normal CLI commands are unaffected.
• Nightly CI workflow (.github/workflows/exercise.yml): builds quantus-node from the chain repo with fast-governance, starts a dev node, runs the suite with --json, uploads report + node log as artifacts. Nightly + workflow_dispatch (with chain ref and fuzz-iteration inputs) rather than per-PR, since node build + QPoW block times dominate.

Test plan

• cargo +nightly fmt --check, clippy --all-targets (no warnings), cargo test --locked (210 passed)
• Full suite green against a local spec-134 fast-governance dev node (all phases except wormhole/upgrade)
• One manual end-to-end run of the upgrade phase with a candidate WASM (--upgrade-wasm) before relying on it for the real upgrade
• First nightly exercise.yml run on CI to validate timing

Known limitations

• Recovery coverage is reads + expected-failure only (CLI has no create_recovery wrapper).
• The upgrade phase has not yet been exercised end-to-end; it needs a WASM with a higher spec version and a fast-governance node.
• Full run takes tens of minutes wall-clock, dominated by QPoW block times, not suite overhead.