Optimise reorg check in CollectLatest mode by deferring to end of collection

Summary

Reduce RPC calls by performing the reorg check only once after the last block range is streamed, rather than checking on every ReorgDetected notification during collection.

Background

Currently, in rewind mode, the scanner handles ReorgDetected notifications as they arrive, invalidating collected logs immediately. This is correct but potentially wasteful since:

1. Reorgs are rare, especially during the collection phase
2. Each reorg check may trigger additional processing

Proposed Optimisation

Defer the reorg check until the collection phase completes. Based on the assumption that reorgs are rare, this reduces unnecessary work in the common case.

Implementation Challenges

Because the event scanner stops BRS (Block Range Scanner) as soon as it collects enough events, BRS can't simply perform a reorg check at the end of the specified rewind block range.

Potential solutions:

1. Add a callback/hook mechanism for the scanner to request a reorg check on-demand

Start with the CollectLatest and rewind collection flow, including ReorgDetected handling and the point where BRS stops after enough events are collected. Determine how an on-demand reorg check could run once after the final streamed block range while preserving log invalidation correctness. Done means the common collection path avoids repeated reorg checks without changing scanner results.