Use consistent chain-state snapshots for multi-query RPC methods

[mpguerra]

Motivation

Several RPC methods issue multiple sequential ReadStateService queries and combine the results into a single response. Each oneshot call independently samples the latest best chain, so a reorg or tip advance between queries can produce internally inconsistent responses. The getrawtransaction instance of this pattern was fixed in PR #10523; three sibling sites remain.

Affected methods

getblock (verbosity 1 and 2) — resolves the header by height, then fetches transactions using the original height instead of the resolved hash. A reorg between the two reads can mix block A's header with block B's transactions. For verbosity 2, transactions from the wrong block are labeled with the resolved block's hash.

getblockheader (verbose) — resolves the header, then fetches SaplingTree and Depth in separate queries. The confirmations field derived from Depth can be stale if the tip advances between queries. The maintainer comment at methods.rs:1494 already acknowledges the reorg race for SaplingTree.

gettxout — issues three separate queries: Tip, Transaction, and IsTransparentOutputSpent. A block landing between the transaction fetch and the spent check can produce a false "unspent" response for an already-spent output. The maintainer TODO at methods.rs:3113-3114 acknowledges this gap.

Fix

Apply the same pattern as the patched getrawtransaction (PR #10523): after the first state query resolves a concrete block hash, use that hash for all subsequent queries. For gettxout, capture the tip from the transaction query rather than issuing a separate Tip request.

Reported by x15-eth (getblock) and lynchmobb (getblockheader, gettxout).

[zmanian]

Adding audit context: the getblock height case looks especially worth fixing by resolving once to a concrete hash and then using that hash for every follow-up query. That avoids mixing header/depth data from one chain view with body/transaction data from another chain view when a non-finalized height changes.

Suggested regression shape for the public consistency bug:

• mock the read-state service so the first height lookup resolves to block A;
• make a later height-based body/transaction lookup resolve to block B at the same height;
• assert the RPC either uses A consistently after the first resolution, or returns a normal error instead of combining A metadata with B contents.

This is the same general pattern as the getrawtransaction fix: bind follow-up reads to the resolved block identity rather than the caller-supplied height.

[mpguerra]

Related: confirmations = -1 causes panic in verbosity-2 transaction serialization

The multi-read consistency gap in this issue has a specific panic path when getblock is called with verbosity 2.

The immediate fix is to handle confirmations = -1 gracefully in the verbosity-2 path (return an RPC error rather than panicking).

The broader fix from this issue (making the state reads atomic) prevents the inconsistency from arising.

Reported by @sangsoo-osec.