fix: Using Block Hash for `from_block`: Handle Unlikely Edge Case that a Reorg Happens Between Scanner Being Started and The First Logs Being Fetched

Becomes relevant after #178 is implemented.

NOTE: since the scanner normalizes from/to blocks, i.e. the client can set to_block to be lower than from_block, when we refer to from_block in this issue, we refer to the block with the lower block number post-normalization.

Current logic is to get the block number associated with the configured from/to block hash at scanner.start, to reduce the chance of a reorg removing the block with the configured hash.

There's an edge case though, where the block hash is set to a non-finalized block and a reorg happens between the scanner being started and the first logs are fetched, meaning by the time the scanner uses the block number previously associated with the block hash that was set, it has already been reorged, and the client would be getting logs from an unrelated, post-reorg block at the same block number.

This edge case is extremely unlikely, but to still address it requires that the event scanner perform a one-time check after the first time it fetches logs that the start block it used has the same hash as the one the client set. After that initial check, the scanner would rely on the existing reorg handling logic.

Start at the scanner.start flow and the first log-fetch operation, then trace the existing reorg handling logic. The work is done when the scanner performs the described one-time check that the start block's hash still matches the configured hash before relying on normal reorg handling.