fix: make world-state hash queries reorg-aware to close getWorldState race

[AztecBot]

Problem

AztecNodeService.getWorldState({ hash }) can intermittently throw

Block hash 0x.. not found in world state at block number N
(world state has no hash at that index ...). If the node API has been queried
with anchor block hash possibly a reorg has occurred.

even when no reorg happened. This surfaced as a flake in oxide / e2e_frozen_notes_refund e2e tests proving a tx that reads existing notes (private-kernel reset resolving a read request anchored on an early block).

Root cause

getWorldState did its world-state sync via #syncWorldState(), which only synced to the archiver's latest height and ignored any requested block hash. It then:

1. resolved the requested hash to a block number against the archiver, and
2. took getSnapshot(N) and read the ARCHIVE leaf at index N to double-check the hash.

The synchronizer reports syncedTo >= N as soon as the height advances, but the archive-tree commit for block N may not yet be visible in the snapshot view. A snapshot taken in that window has populated note/nullifier trees but a half-written archive tree, so getLeafValue(ARCHIVE, N) returns undefined and the double-check throws. The sync-status height and the archive-tree write were not barriered against each other.

Fix

Make the hash-anchored path reorg-aware, as the existing synchronizer plumbing already supports (syncImmediate(targetBlockNumber, blockHash)):

• When the request carries a block hash, resolve it against the archiver up front (fails fast with the existing clear reorg error if the hash is unknown), then drive the sync to that exact (blockNumber, hash).
• WorldStateSynchronizer.syncImmediate reads the committed ARCHIVE leaf for that block; if it is missing or mismatched it forces a blockStream.sync() and re-checks, only throwing on a genuine reorg. This barriers on the archive-tree commit actually landing, closing the race window, and turns real reorgs into a clear block_hash_mismatch instead of a confusing snapshot error.

Block-number / tag queries are unchanged: they still sync to latest height with no hash.

The existing snapshot double-check is kept as a backstop.

Tests

Added unit tests in server.test.ts asserting that a hash-anchored query forwards the resolved (blockNumber, hash) to syncImmediate, and that block-number queries still sync to latest height with no hash. Full yarn-project install/bootstrap (which builds the barretenberg/noir portal packages) was not available in this session, so the suite was not executed here — worth a CI run before merge.

---

Created by claudebox · group: slackbot