perf(consensus): batch block transaction UTXO lookups

[upbqdn]

Motivation

Closes #11185.

Solution

block_spent_utxos issued one zebra_state::Request::AwaitUtxo per transparent input and awaited
each before starting the next, so a transaction with many inputs serialized that many round trips
through the state service.

Adds zebra_state::Request::AnyChainUtxos, which takes a list of outpoints and returns only the ones
already in the queued blocks, any non-finalized chain, or the finalized state. Unlike AwaitUtxo it
never waits and never registers a pending UTXO request, so the block verifier uses it for the bulk of
its lookups and falls back to AwaitUtxo only for outpoints that have not reached the state yet.

Lookups go out in chunks of 64 and stop at the first chunk that is not fully present. That bound is
the reason for chunking rather than sending one request: without it, a transaction whose inputs are
all unknown would make the state look up every input before the sequential fallback failed on the
first, which is more work than the one lookup the old loop did before its timeout. With it, at most
one chunk is speculative.

To be precise about what that bound is and is not: it is additive. A transaction that references
outputs which really are in the state is still looked up in full, exactly as before. The worst case
is old cost plus one chunk, never a multiple of the input count.

Tests

Three new tests in zebra-consensus/src/transaction/tests.rs, each built with a multi-input
transaction and a MockService state, so they assert the request sequence rather than just the
outcome:

• block_utxo_lookups_use_one_bulk_request — one AnyChainUtxos carrying every outpoint in input
  order, then no further state requests.
• block_utxo_lookups_await_only_the_missing_outpoints — one outpoint withheld from the bulk
  response is awaited with AwaitUtxo, and the found ones are not.
• block_utxo_lookups_stop_at_the_first_chunk_with_misses — with 72 inputs and an empty bulk
  response, only the first 64 are ever requested.

Each was checked against the mutation it is meant to catch, and fails without the fix: reversing the
expected outpoint order, withholding a second outpoint, and removing the early break respectively.

Specifications & References

• Bound or batch the per-input UTXO lookups during mempool transaction verification #10697 is the mempool-path sibling of this issue, covering the same shape in
  mempool_spent_utxos (UnspentBestChainUtxo per input). This PR deliberately leaves that path
  untouched.
• AGENTS.md "Security": bound all loops and allocations over attacker-controlled data.

Follow-up Work

• The per-lookup cost is still unmeasured. This reduces request round trips; it does not establish
  how much of block verification's wall clock they account for. task: run the RPC-latency and Regtest mining benchmarks #11041 is the benchmark task that
  should answer it, and its baseline should decide whether the chunk size of 64 is right.
• The lookups within one batch are still serial inside a single blocking task: read::any_utxos
  loops over the outpoints. There is no multi-get in ReadDisk, and ZebraDb::utxo is two dependent
  lookups (tx_loc_by_hash then utxo_by_out_loc), so a genuinely batched DB read is a separate
  change and should also wait for task: run the RPC-latency and Regtest mining benchmarks #11041's measurement.
• The mempool path (Bound or batch the per-input UTXO lookups during mempool transaction verification #10697) can reuse AnyChainUtxos once someone measures whether it needs the
  same treatment.

PR Checklist

• The PR title follows conventional commits format: type(scope): description
• The PR follows the contribution guidelines.
• The solution is tested.
• The documentation and changelogs are up to date.

[v12-auditor]

Note

Complete: Audit complete. V12 did not find any issues that need review.

Open the full results here.

Analyzed six files, diff 5098bdc...6a3df2b.