fix(state): verify zakura header-store invariants in consensus reads

[p0mvn]

Motivation

This PR helps to identify poisoned header-store, and, instead of downscoring a peer for this, silently failing, which prompts a fallback to legacy.

#491 prevents writing/poisoning the store in the first place, and #494 and #496 add auto-repair mechanisms.

Specifically, today, recent_header_context walks the height index blindly, so one stale row inside the 28-height difficulty window makes the node reject every honest header with InvalidDifficultyThreshold.

This has been reproduced and identified via testnet incidents.

This PR catches the poison: corruption found during a read becomes an explicit local error instead of a wrong validation verdict blamed on peers.

Solution

New StoreIncoherentError (exported from zebra-state), returned by readers instead of consuming rows that fail an invariant check:

• recent_header_context verifies as it walks. At every step: the stored header must be the block its hash row names (HeaderHashMismatch — one header hash per consumed row, negligible next to the validation the window feeds), it must link to the row below (BrokenLinkage), and a missing row below a stored one is a Gap, not the end of history (rows are contiguous from genesis: full-block rows below the body tip — retained under pruning — and zakura rows above). A short window is returned only when the walk genuinely reaches genesis; a silently shortened mid-chain window would shift the difficulty adjustment instead of failing.
• The header-hash check closes a subtle edge: parent-link verification alone consumes the window's bottom-edge row unverified (its own link is one step below the window), so a foreign header row whose hash row still matches the chain could poison exactly one entry. Hashing each consumed row makes the walk fully self-verifying.
• Anchor round-trip distinguishes fault domains. A hash the store has never indexed stays UnknownAnchor; a hash→height entry whose height→hash row disagrees is a bijection violation in our own indexes and now reports StoreIncoherent(BijectionMismatch).
• CommitHeaderRangeError::StoreIncoherent is classified Local (non-scoring) in zebrad's header_range_commit_failure_kind: the range was rejected because our store cannot supply trustworthy context, not because the peer's range was shown invalid. This hard-codes the rule that local store incoherence must never score or disconnect peers.

StoreIncoherent rejections are side-effect free (validation happens before any batch write), so the store is untouched and the fault can only trigger recovery — on the fleet branch the ContextMismatch/walk-back machinery picks it up; Pillar 3's audit-and-repair is the end state.

[v12-auditor]

Note

Complete: Audit complete. No review-worthy issues remain after automatic triage. Three findings were auto-invalidated.

Open the full results here.

Analyzed five files, diff 93d3456...08f791a.

[p0mvn]

@cursor review

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 4459656. Configure here.}

[evan-forbes]

for our future selves, I think we can avoid keeping the zebra mixing of logic for state and reactor/services at least slightly

easy approve tho

[evan-forbes]

there are some minor compile issues and conflicts I'll clean up quickly then merge