fix(archiver): clean up removed blocks from raw rows and ownership-check tx-effect deletes

[spalladino]

Problem

Two defects in BlockStore block removal could corrupt the tx-effect index (txHash → owning block hash/position) if the store ever held two blocks sharing a tx:

1. Blind delete — deleteBlock removed #txEffects entries by txHash without checking the entry still pointed at the block being deleted. If another stored block contained the same tx, that block's entry was destroyed collaterally, making the block unreadable (Could not find tx effect for tx…).
2. Skip-on-unreadable leak — removeBlocksAfter did getBlock(bn) === undefined → warn + continue, so an unreadable block's row, tx effects, and indices were never released. A later addCheckpoints overwrites the leaked row in place ("L1 data is authoritative"), leaving stale tx-effect entries pointing at coordinates now occupied by different txs — getTxReceipt then reports positions the chain no longer has, and getL2ToL1MembershipWitness resolves the wrong tx and throws The L2ToL1Message you are trying to prove inclusion of does not exist.

This is hardening, not an incident fix. No honest code path produces two stored blocks sharing a tx: duplicate nullifiers are rejected at block building (double-spend validation against the build fork), at validator re-execution, and at world-state sync (nullifier leaves are non-updateable). The incident that prompted the investigation turned out to be a downstream client bug following a v5 behavior change in L2BlockSynchronizer, unrelated to the store. The store should still not amplify a duplicated-tx state into silent corruption if it ever appears — e.g. via a future upstream bug, or byzantine tx effects that repeat a txHash with distinct nullifiers (invisible to every nullifier-based check).

Fix

• removeBlocksAfter cleans up from the raw storage row, so blocks whose bodies can no longer be fully loaded still release their row, tx effects (enumerated from #blockTxs), and hash/archive indices.
• deleteBlock only deletes a tx-effect entry still owned by the block being removed (compares the entry's leading block hash).
• Both anomalies now log a warning (an entry owned by another block, or a missing entry). These states should be unreachable, so a warning in production logs is direct evidence of an upstream bug worth investigating — previously the ownership skip was silent, hiding exactly that signal.

Cost

The added reads are confined to prune/reorg paths: one #blockTxs read plus one tx-effect point read per tx of each removed block (roughly doubling point reads on block removal). Block ingestion and query paths are untouched.

Verification

• Regression test from fix(archiver): fully clean up removed blocks whose txs were re-included elsewhere #24732: two proposed blocks sharing a tx effect; asserts removal releases both blocks fully with no residue (fails on the pre-fix implementation).
• Full block_store.test.ts suite passes (160 tests).

Recreates #24732 with the original commit cherry-picked and authorship preserved (thanks @benesjan). On top of it, this PR updates the description and code comments to match what the follow-up investigation established about how a duplicated-tx state can and cannot arise, and adds the anomaly warnings. Supersedes #24732.

Related to A-1426

[AztecBot]

✅ Successfully ported to port-to-next-staging #24964.