perf(state): bypass write buffer for read-only state requests

[evan-forbes]

Motivation

The transaction verifier and mempool send read-only requests through the
serialized read-write state buffer. The read-write service immediately forwards
those requests to the existing read service.

The preserved 80-node campaign observed 12,589,364 requests through the outer
buffer. These changes can bypass that buffer for at least 7,868,996 requests.
The upper bound is 12,142,479 requests, or 96.45% of observed traffic.

The request count measures removed buffer work. It does not establish a latency
saving.

Solution

• Route transaction-verifier nullifier, anchor, median-time-past, and best-chain
  UTXO reads directly to ReadStateService.
• Keep block AwaitUtxo requests and every write on the read-write service.
• Route mempool best-chain transaction and tip reads directly to
  ReadStateService.
• Retain the read-write state handle as a mempool lifetime guard.
• Add routing tests that prove read-only and waiting requests reach the correct
  service.
• Assert that the mempool never sends requests through the retained write-state
  guard.
• Remove mempool read concurrency from the write-state buffer budget.

Safety

The read-write state service already forwards these request variants to a clone
of the same read service. The change removes one outer buffer hop. It does not
change the query implementation, non-finalized snapshot source, request bounds,
or write ownership.

The routed requests stop incrementing the outer service="state" request
series. The existing service="read_state" series continues to count them.
Block AwaitUtxo readiness now falls inside the transaction-verifier timeout.

Results

The release benchmark sends 100,000 sequential median-time-past reads per
sample. It wraps the production TransactionStateRouter in a bound-one Tower
buffer for the baseline. The direct arm uses the same router and fixed response
without that buffer. Five invocations collected ten samples per arm.

Route	Median latency per request
Buffered	3.622 us
Direct	0.054 us
Removed dispatch	3.568 us (98.5%)

This unloaded benchmark isolates dispatch. It does not include state query work
or CPU saturation. The preserved fleet counts show how often the node removes
the hop. They do not convert the unloaded result into an end-to-end latency
claim.

Validation

• cargo bench -p zakura-consensus --bench state_read_routing --features internal-bench
• cargo test -p zakura-consensus --lib --locked: passed
• cargo test -p zakura --lib --locked: 405 passed; one baseline test failed
• cargo clippy -p zakura-chain -p zakura-consensus -p zakura-state -p zakura --all-targets -- -D warnings
• cargo fmt --all -- --check
• git diff --check

The baseline failure is
inbound_pruned_block_is_not_advertised_and_getdata_logs_error. The focused
test also fails on untouched main.

Changelog

This PR adds docs/changelog/unreleased/784.md.

Stack

• Base: main.
• Parent: none.
• Children: none.
• This PR is independent of feat(mining): advertise admitted blocks optimistically #748, feat(mining): submit prepared blocks by solved header #754, perf(consensus): accelerate block verification #776, perf(state): avoid contextual UTXO copies #779, perf(state): share contextual snapshot maps #780, perf(state): measure mined block admission timing #781, perf(state): measure contextual verification phases #782, and feat(consensus): relay expected-work blocks before contextual commit #773.

[ValarDragon]

Awesome! Nice job on this