`FilterIter` may not handle reorgs properly.

[evanlinjin]

We need to test this against reorgs. It seems like the architecture of this may result in inconsistent state of checkpoints during reorgs.

1. Have a chain with blocks .. [100:A] [101:B] with relevant txs in both A and B.
2. Sync up to 100 (calling .next).
3. Reorg so that blocks from 100 are replaced (inclusive). .. [100:A'] [101:B'].
4. Call .next again.
5. Check that checkpoints end in .. [100:A'] [101:B'] and we have emitted relevant txs in A' and B'.

Originally posted by @evanlinjin in https://github.com/bitcoindevkit/bdk/issues/1614#issuecomment-2672023986

[Musab1258]

@evanlinjin, can I work on this?

[ValuedMammal]

To fix this I would avoid this pre-fetching of blocks and just fetch every block hash/header by height. If we encounter a header with a previous hash that doesn't match the previously emitted block id, we know we need to backtrack and refetch filters until we've formed a consistent chain.

https://github.com/bitcoindevkit/bdk/blob/ea150b4db9c3b6cdcb3d8af406b649ad49ce0fb1/crates/bitcoind_rpc/src/bip158.rs#L104-L106

I wonder is it necessary to perform this reorg check at every height in a scan or only the blocks that lie within some fixed arbitrary distance from the stop block?