Add zingo consensus

[zancas]

What

• New zero-dependency workspace member zingo-consensus holding ActivationHeights, ActivationHeightsBuilder, and NetworkType, ported from zingo_common_components 0.4.0 (nu6.3 included). BlockHeight, TxId, and H0 are not ported: an org-wide audit found zero consumers.
• The all-heights-one regtest schedule is the type's documented Default impl, replacing the old for_test::all_height_one_nus helper.
• zcash_local_net consumes it by path and re-exports the builder alongside the two types it already re-exported, so consumers can construct the type without a direct dependency.
• regtest-launcher consumes the zcash_local_net::protocol re-exports and holds no direct dep, per the dependency rule below.
• Now that Add client support #270 landed add_client_support on dev, this branch merges dev and the diff is purely the zingo-consensus work. The client code's five zingo_common_components references are swapped to zingo-consensus. Note for the zaino side: zaino's drop_zingo_common_components branch currently pins 0a003b4 on this branch; after this merges, that pin should move to the merge commit or the release tag.

Why

Phase 1 of the zingo-common disintegration (see docs/DISINTEGRATION.md in zingolabs/zingo-common). Every network upgrade currently walks a four-repo publish cascade through zingo-common. Co-locating the vocabulary with its main consumer removes one hop, and the leaf-crate shape keeps wallet builds free of the harness: zingolib pulls only this crate, behind its default-off regtest feature (zingolib ADR 0002).

Dependency rule: a crate that depends on zcash_local_net takes the vocabulary through its protocol re-exports and must not also directly depend on zingo-consensus. The only direct dependents are zcash_local_net itself and zingolib's optional regtest feature.

Verification

cargo check --workspace --all-features, cargo clippy --workspace --all-features, and cargo fmt --all -- --check are clean. cargo nextest run -p zingo-consensus passes 5/5.

After merge

Tag and publish zingo-consensus to crates.io, then flip the git pins in zingolib (add_regtest_gate) and zaino (drop_zingo_common_components) to the tag.

🤖 Generated with Claude Code

[dannywillems]

utACK 0a003b4.

However, I see the following deps used in Cargo.toml:

#zcash
zcash_protocol = { version = "0.9.0", features = ["local-consensus"] }

# zebra
zebra-chain = "9.0.0"
zebra-node-services = "7.0.0"
zebra-rpc = "9.0.0"

Are they not already defining the structures for the network type and activation heights? If yes, it would be easier to maintain the whole Z3 stack if we avoid duplication.

[zancas]

Good questions, to be continued...