rpc: Add JSON-RPC methods for working with PCZTs

[sellout]

Implements the PCZT (Partially Created Zcash Transaction) JSON-RPC methods requested in #99, as the modern, robust replacements for createrawtransaction, fundrawtransaction, and signrawtransaction.

Supersedes #354 (thanks @lamb356 for the initial implementation) — this branch rebuilds that work on current main, addresses all of @nullcopy's review feedback, and fills in the structural gaps.

Closes #99.

Methods

A transaction is assembled by threading a PCZT through these roles:

Method	Role(s)	Notes
pczt_create	propose_transfer + create_pczt_from_proposal	Build a funded PCZT from a payment request (≈ createrawtransaction + fundrawtransaction).
pczt_combine	Combiner	Merge several parties' contributions.
pczt_prove	Prover	Add the Sapling/Orchard proofs (run off the async runtime; caches the Orchard proving key).
pczt_sign	Signer	Sign with the wallet's keys.
pczt_extract	SpendFinalizer + TransactionExtractor	Finalize spends and verify before extracting the final transaction.

The stateless roles (combine/prove/extract) live in the general Rpc trait; create/sign require wallet state.

Notes for review

• pczt_create vs pczt_fund. feat: Add PCZT RPC methods (issue #99) #354 named this pczt_fund; @nullcopy noted that "fund" reads like adding funds to an existing PCZT. That operation (≈ fundrawtransaction on a partial PCZT) is effectively infeasible at the pinned librustzcash rev: create_pczt_from_proposal IO-finalizes its output (permanently clearing tx_modifiable), there is no Constructor implementation or Builder-from-PCZT path, and no input-selector API for a "cover the remaining value" target. So this method builds a complete PCZT from a payment request in one shot (matching zcash-devtool's pczt create), and pczt_create is the accurate name.
• Shared logic. pczt_create reuses payments::AmountParameter + build_request (from Extract the shared amount parameter into a reusable payments type #535) and a new shared payments::propose_and_check helper (privacy-policy validation → propose → enforce → Orchard-action-limit) that z_sendmany now also uses, so the two stay in sync.
• Signing hints. pczt 0.7 exposes no public getter for the native BIP 32 / ZIP 32 derivation metadata, so pczt_create records zallet.v1.* proprietary fields for an offline pczt_sign to read back — a stand-in for the native path until upstream adds accessors.
• pczt_extract verifies. It runs the spend finalizer and verifies all proofs/signatures (supplying the bundled Sapling verifying keys) before producing the transaction, rather than deferring to the network.

Dependencies

Adds pczt 0.7, pinned to the same librustzcash revision as the other [patch.crates-io] crates, and enables the zcash_client_backend/pczt builder support plus zcash_client_sqlite/serde (required for AccountUuid: Serialize, which create_pczt_from_proposal needs).

Testing

• Unit tests for the base64 decode size/format limits and the pczt_combine caps.
• cargo clippy --all-targets -- -D warnings clean; full zallet lib test suite green.
• ⚠️ No automated end-to-end shielded test. The zcash_client_backend data_api::testing framework can't be used from a downstream crate at the pinned rev — its only concrete store factory (zcash_client_sqlite::testing) is #[cfg(test)]-only, and there is no zcash_client_memory crate at this rev — so the full create → prove → sign → extract path is verified by manual regtest for now. A follow-up could vendor a minimal in-memory store factory to unlock a node-free CI test.

---

Rebased onto main @ 4fa38e1. The commits on this branch are currently unsigned.

[schell]

there is no zcash_client_memory crate at this rev — so the full create → prove → sign → extract path is verified by manual regtest for now. A follow-up could vendor a minimal in-memory store factory to unlock a node-free CI test

I think this is the biggest deal here, and obviously it's out of scope for this PR, so I've opened zcash/librustzcash#2623 to track that.

Other than that the only thing that jumps out at me is that there's a number of discarded errors and I wonder if it might be good to either roll those into the mapped messages or create variants in the mapped-to error enum? Not a biggy though.

Let me know when it's ready for another pass and I'll give it my stamp 🙇 .