Wire zcash_voting + tree crates for crates.io publish

[czarcas7ic]

Summary

Phase 4 prep: make vote-commitment-tree, vote-commitment-tree-client, and zcash_voting publishable on crates.io now that all upstream dependencies (pir-client, voting-circuits, valar-orchard, valar-pczt) have been published.

What changed

Dep rewiring (the headline — required for publish):

• All git-deps swapped for crates.io releases:
  • pir-client 0.1.0 (was git rev)
  • voting-circuits 0.1.0 (was git HEAD)
  • pczt → valar-pczt 0.5.1 (package rename; was git rev pinned to librustzcash fork)
  • Sibling tree crates: path + version pairs so crates.io resolves the version while dev builds stay local.
• Deleted the workspace [patch.crates-io] block — the pinned librustzcash rev + voting-circuits git ref are superseded by the published valar-* forks, and crates.io doesn't let published crates carry a patch table anyway.

Metadata for publish:

• description / license (MIT OR Apache-2.0) / repository / readme keys added to all three crates' Cargo.toml.
• LICENSE-MIT + LICENSE-APACHE at repo root.
• Per-crate README.md describing purpose + usage snippet.

Dual orchard in zcash_voting — the subtle bit:

zcash_voting sits at a dep-graph boundary where it consumes upstream orchard types (from zcash_keys, valar-pczt internals, zcash_primitives) and produces valar-orchard types (consumed by voting-circuits, which needs the governance-visibility methods we added). Cargo distinguishes these two crates by package name, so a single use orchard::… line can't satisfy both callsites.

Attempted but ruled out:

• [patch.crates-io] orchard = { git=…, package = "valar-orchard" } — would need a second patch for valar-orchard too, which cargo rejects as "two patches resolve to the same result".
• Forcing everything to valar-orchard — UnifiedSpendingKey::orchard() returns upstream SpendingKey; we can't make zcash_keys return valar types without cascade-forking zcash_keys, zcash_primitives, etc.
• Forcing everything to upstream orchard — voting-circuits's public API uses valar-orchard types that require pub(crate) → pub visibility changes not present upstream.

Implementation:

• Two Cargo.toml deps with the package = rename trick:
  • orchard → valar-orchard 0.11.0 (for voting-circuits callsites)
  • orchard_upstream → upstream orchard 0.11.0 (for zcash_keys / zcash_primitives / PcztParts)
• New zcash_voting/src/orchard_compat.rs with two byte-round-trip helpers (fvk_upstream_to_valar, sk_upstream_to_valar). Safe because valar-orchard is a pure superset of upstream with identical wire formats — the helpers go to_bytes() → from_bytes().
• Conversions happen only at the zcash_keys boundary: zkp1.rs::reconstruct_note + zkp2.rs::derive_spending_key.
• action.rs uses orchard_upstream throughout because it builds a bundle that plugs into PcztParts.orchard (upstream-typed). Uses only standard orchard APIs, no governance-visibility methods needed.

Exit plan: when the valar-orchard visibility changes land in zcash/orchard upstream, drop orchard_upstream + orchard_compat.rs, point orchard at upstream directly. Clean exit.

Test plan

• cargo check --workspace --all-targets clean (no warnings)
• cargo test --workspace --lib — 84/84 pass (long-running Halo2 proof test test_real_delegation_proof skipped per normal)
• Dry-run publish each crate locally (user will run cargo publish --dry-run -p vote-commitment-tree then -p vote-commitment-tree-client then -p zcash_voting)