feat: reorg handling

[pthmas]

Summary

Atlas currently has no chain reorganization handling. If the chain reorgs, previously indexed blocks may become orphaned and the explorer will serve inconsistent data (e.g., transactions that no longer exist on the canonical chain).

Motivation

Any EVM chain can experience reorgs. Without handling them, Atlas may:

• Show transactions/blocks that were reverted
• Miss the canonical replacement blocks
• Have inconsistent state in derived tables (ERC-20 balances, NFT ownership)

This is a correctness issue, not just a performance one.

Design

Detection

1. On each new batch, validate the parent hash of the first block against the stored hash of the previous block
2. If mismatch detected, walk back up to N blocks (e.g., 128) to find the fork point

Rollback

1. Delete orphaned blocks and all associated data (transactions, logs, transfers, etc.) from the fork point onward
2. For partitioned tables, deletion needs to target the correct partitions
3. Update derived tables (ERC-20 balances, NFT ownership) — either recompute or reverse the orphaned changes
4. Update indexer_state watermark to the fork point
5. Resume indexing from the fork point

Considerations

• Derived tables (erc20_balances, nft_tokens) make rollback more complex than raw-data-only indexers — may need to replay transfers from the fork point
• The HeadTracker in-memory buffer needs to be pruned of orphaned blocks
• SSE clients should be notified of the reorg (new event type or resync signal)
• Configurable max reorg depth (default 128, matching tidx)
• Optional trust_rpc flag to skip parent hash validation for trusted RPCs

References

• tidx implementation: sync/engine.rs — find_fork_point walks back, deletes orphans from all sinks