Bump zk-circuits crates to 4.3.0 (new wormhole circuits)

[n13]

Bumps the seven zk-circuits pins (qp-wormhole-*, qp-zk-circuits-common) from 4.2.0 to 4.3.0 and adapts wormhole_lib.rs to the 4.3.0 input layout: input_amount moved from PrivateCircuitInputs to PublicCircuitInputs (it is now the 22nd leaf public input, consumed by the aggregate per-segment fee check).

Verified locally: cargo check --all-targets passes; the build script regenerates all circuit binaries with hashes identical to chain's pallet-wormhole build against 4.3.0 (e.g. private_batch_common.bin 24882d6f…, public_batch_verifier.bin 7e960fae…), and DEFAULT_NUM_PRIVATE_BATCH_PROOFS = 53 still matches the chain default.

Ship this as a CLI release (2.1.1 → 2.1.2): the runtime generated-bins cache quarantines on a CARGO_PKG_VERSION mismatch (bins.rs), so installed binaries only regenerate the 4.3.0 artifacts when the CLI's own version changes. Dev builds republish generated-bins/ on every build regardless.

Companion to Quantus-Network/chain#684 — proofs from this CLI verify only against a chain running the 4.3.0 verifier.

Cooldown-bypass-reason: first-party qp-wormhole 4.3.0 crates published by our own CI; the chain moves to the 4.3.0 verifier (chain#684) and CLI proofs must match it, so holding at 4.2.0 for 30 days breaks proving.

[n13]

Reviewer model: GPT Sol

Verdict (advisory): Approve

No blocking findings.

The 4.3.0 dependency stack is coherent and the CLI adaptation matches the new circuit contract: input_amount is sourced from the spent ZK-tree leaf, registered as the 22nd authenticated leaf public input, and consumed by the private-batch wrapper's aggregate per-segment fee constraint without being forwarded by either aggregate proof layer. The merged chain companion now pins the same seven 4.3.0 crates and uses the same 7-leaf/53-private-batch sizing.

Release condition: ship this through the separate 2.1.2 version-bump/release flow immediately after merge, as the PR states. The artifact manifest invalidates on CARGO_PKG_VERSION and sizing, so a source-built 2.1.1 binary can otherwise accept an already authenticated 2.1.1 cache containing 4.2.0 artifacts. The repository's version bump is intentionally handled by a separate release-proposal workflow, so this does not block the dependency patch, but the intermediate same-version source build should not be treated as deployable.

Validation:

• cargo +nightly-2026-08-31 fmt --all -- --check
• cargo test --locked test_public_inputs_structure — passed in both library and binary targets
• cargo test --locked --lib bins::tests — 15 passed
• cargo test --locked --lib wormhole_lib::tests — 5 passed, including successful proof generation
• Full circuit generation at defaults 7/53 — generated hashes matched the PR's chain-side examples (private_batch_common.bin 24882d6f…, public_batch_verifier.bin 7e960fae…)
• git diff --check

All reported GitHub checks are green at b3b156334278370dd645724523fe8ec2e4ae78d7: format, dependency cooldown, Ubuntu/macOS build-and-test, Clippy/docs, security audit, and examples.