rpc: add conformance coverage for wallet RPC methods that mirror Zebra/zcashd

[peter941221]

I think the recent wallet RPC bug reports point to one shared gap: Zallet does not yet have regression coverage for response-shape compatibility on wallet RPC methods that intentionally mirror Zebra or zcashd.

Evidence from the current open issue cluster:

1. rpc(z_viewtransaction): SqliteFailure "no such column: tx" for all wallet-owned transactions #440 reports that z_viewtransaction fails outright for wallet-owned transactions because the wallet-side query path is missing coverage.
2. rpc(z_listunspent): address field absent on walletInternal=true change outputs #441 reports that z_listunspent omits the address field on walletInternal change outputs, which breaks typed clients that treat the response schema as stable.
3. rpc(getrawtransaction): reply omits in_active_chain and vjoinsplit relative to Zebra #442 reports that getrawtransaction omits in_active_chain and vjoinsplit relative to Zebra for the same txid and verbosity.

These look different on the surface, but they have the same downstream effect: client code that treats same-named wallet RPC methods as stable adapters over Zebra or zcashd behavior has to learn Zallet-specific exceptions one bug at a time.

I think we should add explicit conformance coverage for the wallet RPC methods where response-shape compatibility matters most to downstream consumers. My suggestion is to start with the methods that already have open shape or serialization bugs:

1. getrawtransaction
2. z_listunspent
3. z_viewtransaction

I am not proposing that every field must be byte-for-byte identical to every backend forever. I am proposing that for methods intentionally exposed under the same names, we should have regression tests that lock the fields and invariants that client code is expected to rely on.

A concrete first step would be:

1. add focused regression tests for the current failures in rpc(z_viewtransaction): SqliteFailure "no such column: tx" for all wallet-owned transactions #440, rpc(z_listunspent): address field absent on walletInternal=true change outputs #441, and rpc(getrawtransaction): reply omits in_active_chain and vjoinsplit relative to Zebra #442;
2. group those tests under a small wallet RPC conformance area so future parity regressions land in one place;
3. document any intentional divergences when the wallet cannot or should not match Zebra or zcashd.

If this direction makes sense, I can put together the first patch starting with #442 and the associated regression coverage.

[linear]

COR-1285

[peter941221]

I took a first pass at the RPC conformance work under this umbrella and kept the scope narrow on purpose.

The patch only addresses the in_active_chain part of #442. I left vjoinsplit alone for now because that path is still behind #[cfg(zallet_unimplemented)] in get_raw_transaction.rs, so bundling it into the same PR would turn a small parity fix into a larger transaction-shape change.

The local change does three things:

1. It populates in_active_chain in verbose getrawtransaction responses when Zallet already has enough metadata to infer it from the returned block context.
2. It adds focused method-level regression tests around that response shape.
3. It leaves concise mode and the current blockhash parameter behavior unchanged.

I verified the change in a clean WSL worktree with:

1. cargo +stable fmt --all -- --check
2. cargo +stable check -p zallet --lib
3. targeted unit tests for:
   • infer_in_active_chain_only_when_block_context_is_known
   • verbose_transaction_serialization_includes_in_active_chain_for_mined_txs
   • concise_mode_serialization_is_unchanged

If this scope looks acceptable, I can open a draft PR for the #442 slice first, then follow up on #440 separately. I would leave #441 for a later product/API decision, since the current listunspent implementation and docs both intentionally omit address when walletInternal=true.