fix(jsonrpc): post log/block filters for reorg-applied blocks

[0xbigapple]

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

[bladehan1]

[NIT] Document all known gaps between reApplyLogsFilter and blockTrigger

reApplyLogsFilter mirrors only the FULL JSON-RPC filter portion of blockTrigger. Three additional responsibilities that blockTrigger carries are absent on the reorg path, and none of them are recorded in the code:

1. Switch-back (failed-rollback) path is uncovered. reApplyLogsFilter(first) sits after the for-loop in switchFork, so an exception thrown by applyBlock propagates before this line is reached — intentionally leaving the failed-rollback path without filter notifications. This is correct behaviour, but without a comment a future maintainer changing the exception handling (e.g. adding retry logic) may inadvertently introduce duplicate or missing filter events.

2. Event-subscribe triggers are not fired. On the normal extend path blockTrigger also calls postBlockTrigger(block) and postSolidityTrigger(newSolid) (event-subscribe v0), and updates lastUsedSolidityNum (event-plugin v1). None of these happen for blocks applied through switchFork. dApps relying on WebSocket event subscriptions will silently miss block and transaction events for every reorg'd block. This is documented in the PR description as a known limitation, but there is no in-code record.

3. postSolidityFilter is not called here. blockTrigger also calls postSolidityFilter(oldSolid, newSolid) for solidity-JSON-RPC-enabled nodes. Solidification events for reorg'd blocks do eventually arrive when the solidification height advances and a subsequent blockTrigger call invokes postSolidityFilter against the (now-updated) canonical chain — but this deferred-coverage contract is implicit and unrecorded.

4. Future divergence risk. Because reApplyLogsFilter is an explicit partial mirror of blockTrigger, any future addition to blockTrigger will silently be absent from the reorg path. Without a comment linking the two methods, this is easy to miss.

Suggestion: Add a Javadoc or block comment above reApplyLogsFilter listing the out-of-scope items (event subscribe, postSolidityFilter deferred path, switch-back) and noting that this method must be kept in sync with the FULL-filter section of blockTrigger. Add a short inline comment at the reApplyLogsFilter(first) call site noting that it only runs on the successful reorg path.

[bladehan1]

[NIT] Documentation & test backlog (2 items rolled up)

Grouped as one comment since both are doc-or-test asks with no production-code impact.

1. BlockFilterCapsule not asserted for the reorg path. reApplyLogsFilter calls both postBlockFilter(false) and postLogsFilter(false, false), but hasFullLogsFilter only inspects LogsFilterCapsule instances. The BlockFilterCapsule items produced for eth_newBlockFilter subscribers are unverified: if postBlockFilter were removed or broken, the test would still pass. Consider adding a helper analogous to hasFullLogsFilter that checks for a BlockFilterCapsule with the expected block hash, and asserting it for b1 and b2 after the reorg.

2. hasFullLogsFilter name is broader than its implementation. The method name implies it validates the full FULL-node filter pipeline, but the body filters exclusively for LogsFilterCapsule. This can mislead a future reader who might expect it covers block filters too. Consider renaming to hasLogsFilterCapsule, or adding a brief Javadoc clarifying the scope.

Suggestion: (1) Add a hasBlockFilterCapsule(queue, b) helper and assert it for b1/b2 in the reorg test; (2) rename or annotate hasFullLogsFilter to reflect its actual scope.