fix: detect reorged sidechain blocks by canonical hash

[YoGhurt111]

Summary

• Detect reorgs by comparing a previously scanned block against the current canonical block at the same height.
• Require buffered common-ancestor candidates to still be canonical before accepting them.
• Add a regression test for providers that keep reorged sidechain blocks queryable by hash.

Root Cause

Some execution clients can still return a reorged sidechain block from eth_getBlockByHash after the canonical block at the same height has changed. The previous reorg check treated a successful hash lookup as proof that the buffered/scanned block was still canonical, so same-height replacements could be missed and the affected range would not be replayed.

Testing

• cargo test --features test-utils detects_reorg_when_old_hash_is_available_but_not_canonical
• cargo check --features test-utils

Note: cargo fmt --check on this machine reports unrelated formatting diffs in existing files (src/block_range_scanner/common.rs and src/event_scanner/block_range_handler.rs) due to the stable rustfmt handling of the repository rustfmt config. Those unrelated files were not changed in this PR.

[0xNeshi]

Confirmed the finding that Geth can return a non-canonical block by hash, if the block is still in the node's DB.

Sources:

• rawdb docs state it stores both canonical and non-canonical blocks
• eth_getBlockByNumber is explicit about returning only canonical blocks at the specified height, while eth_getBlockByHash isn't.

@YoGhurt111 feel free to list other clients that do the same

[0xNeshi]

Looks good, thank you!

[0xNeshi]

We have a signed commit requirement, so closing this PR with unsigned commits in favor of #354