fix(archiver): reconcile local blocks with L1 checkpoints by block number

[spalladino]

Motivation

When the sequencer locally proposed block N at slot S1 and L1 mined a different block N at slot S2 (same block number, different slot), the archiver's reconciliation in pruneMismatchingLocalBlocks joined local↔checkpoint blocks by slot and missed the conflict. The local block was never pruned and the subsequent re-apply of L1's block N threw Contract instance ... already exists, cannot add again at block N. The archiver's serial queue then retried in a loop and wedged the data store — this is the cause of the e2e flake at yarn-project/end-to-end/src/composed/ha/e2e_ha_full.test.ts:693.

Approach

pruneMismatchingLocalBlocks now keys conflict detection on blockNumber only, so a same-number-different-slot block is correctly detected as a conflict and pruned. The per-checkpoint trailing prune (which handles "local has extra blocks at the same slot as the published checkpoint") stays scoped by slot so speculative blocks at later slots that belong to a pending proposed checkpoint are preserved — this keeps the pipelining model in promoteProposedToCheckpointed intact. After any prune, pending proposed checkpoints from the offending checkpoint number onwards are evicted so they do not dangle while referencing removed blocks.

Changes

• archiver: pruneMismatchingLocalBlocks joins by blockNumber only; trailing slot-scoped prune unchanged; new evictProposedCheckpointsForPrunedBlocks helper clears stale pending proposed checkpoints after a prune.
• archiver (tests): four new regression tests in data_store_updater.test.ts covering the e2e_ha scenario, the prune-by-number path without contract data, pipelining preservation, and eviction of higher-numbered proposed checkpoints chaining off pruned blocks.