What does this PR do?

Adds reApplyLogsFilter(List<KhaosBlock>), invoked after switchFork has fully applied the new branch (oldest-first), mirroring blockTrigger's jsonrpc FULL handling so reorg'd blocks reach the FULL stream like the normal extend path.

Why are these changes required?

On a reorg, pushBlock calls switchFork() and returns early, never reaching blockTrigger() — the only place that posts the "added" FULL filters (postBlockFilter / postLogsFilter(block, false, false)). The rollback side withdraws the orphaned branch's logs (reOrgLogsFilter, removed=true), but nothing re-posts the new branch's logs: withdraw old, never add new, violating reorg semantics.

So dApps using eth_newFilter + eth_getFilterChanges miss every log in blocks applied via switchFork.

This PR has been tested by:

• Unit Tests
• Manual Testing

Follow up

• Failed-rollback (switch-back) path — new branch's logs not re-posted; out of scope, known limitations
• Event-plugin block/transaction triggers — not posted on the reorg path; out of scope, known limitations

Extra details