Add gRPC parity test suite: Zainod vs. Lightwalletd backed by Zebrad

[pacu]

Problem

There is no automated way to detect behavioral regressions between Zainod and Lightwalletd when serving the CompactTxStreamer gRPC protocol. Divergences can go unnoticed until they affect light wallet users.

Proposal

Add a test suite to this repo that runs Zainod and Lightwalletd side-by-side against the same Zebrad node and compares their responses across all CompactTxStreamer RPC methods. The suite should integrate with the existing BitcoinTestFramework and CI pipeline, and be triggerable from the Lightwalletd repo via repository_dispatch.

Scope

In scope:

• All read-only CompactTxStreamer methods: GetLightdInfo, GetLatestBlock, GetBlock, GetBlockNullifiers, GetBlockRange, GetBlockRangeNullifiers, GetTransaction, GetTaddressTxids, GetTaddressBalance, GetTaddressBalanceStream, GetTreeState, GetLatestTreeState, GetSubtreeRoots, GetAddressUtxos, GetAddressUtxosStream
• Error path coverage (out-of-bounds requests)
• CI integration with cross-repo dispatch trigger from Lightwalletd

Out of scope for this iteration:

• GetMempoolTx / GetMempoolStream — require wallet integration to submit mempool transactions
• Shielded transaction coverage — requires Zallet integration or a chain cache with pre-existing shielded activity
• GetSubtreeRoots with completed subtrees — each requires 2^16 outputs; not feasible in a clean regtest chain
• SendTransaction
• Darkside mode

Known divergences to investigate

Two behavioral differences between Zainod and Lightwalletd surfaced during implementation and are worked around but unresolved:

1. vtx in compact blocks — For blocks containing only transparent transactions, Zainod returns an empty vtx while Lightwalletd includes them. Whether this is a bug, a protocol interpretation difference, or expected behavior is unclear.

2. gRPC error codes on out-of-bounds requests — Zainod returns OUT_OF_RANGE; Lightwalletd returns INVALID_ARGUMENT for the same inputs.

[linear]

COR-1186