fix(event): correct fork rollback handling in solidity event maps

[xxo1shine]

What does this PR do?

Fix two correctness bugs in event service rollback handling that cause solidity-side event/log triggers to either leak fork- removed entries or be lost during reorg.

When a block is rolled back during fork resolution, its contract triggers are marked removed=true. The solidity event pipeline depends on this flag plus an in-memory map (Args.getSolidityContractEventTriggerMap / getSolidityContractLogTriggerMap) keyed by block number. Two paths through this pipeline were broken:

1. Removed triggers reached the solidity sink. ContractTriggerCapsule.processTrigger()
   only checked isSolidityEventTriggerEnable / isSolidityLogTriggerEnable, never the
   removed flag. Triggers from forked-out blocks were emitted as valid solidity events.

2. Async enqueue raced with reorg cache clearing. Manager.postContractTrigger
   posted to a global triggerCapsuleQueue for async draining, but
   reOrgContractTrigger clears the in-memory cache synchronously. Capsules already
   in the queue could reference state that was about to be invalidated, leading to
   either lost events or stale cache reads.

3. Solidity caches were not cleared on block-process failure or shutdown.
   getSolidityContract{Log,Event}TriggerMap entries are populated per block.
   If processBlock threw after population, or on node shutdown, those entries
   leaked.

Why are these changes required?

This PR has been tested by:

• Unit Tests
• Manual Testing

Follow up

Extra details

Fixes #6678

[0xbigapple]

[SHOULD] clearSolidityContractTriggerCache guard is narrower than the write side; redundancy path leaks the map.
ContractTriggerCapsule.java:162 ( the event-as-log redundancy path) also writes to solidityContractLogTriggerMap under this combination:

isContractLogTriggerEnable      = true
isContractLogTriggerRedundancy  = true
isSolidityLogTriggerRedundancy  = true
isSolidityLogTriggerEnable      = false
isSolidityEventTriggerEnable    = false

outer condition (isContractLogEnable && isContractLogRedundancy) || ... is true → enters the redundancy block; inner isSolidityLogTriggerRedundancy=true → writes to the solidity log map. But both clear-side guard predicates are false → clear is skipped.

Subtler still: the consumer postSolidityTrigger is also gated by isSolidityLogTriggerEnable, so under this configuration the consumer does not run either. The result: solidityContractLogTriggerMap accumulates one entry per event-bearing block, never consumed, never cleared — a memory leak. It does not produce Issue #6678's "duplicate downstream events" symptom (no downstream is wired up), but since the PR formalizes the clearing responsibility, the clear's semantics should be aligned with the write side.

Suggestion (preferred): simply drop the guard. ConcurrentHashMap.remove(key) on a non-existent key is an O(1) bucket lookup returning null — the cost is negligible. The guard was only a defensive optimization; without it, write-side condition changes won't desync the clear:

private void clearSolidityContractTriggerCache(long blockNum) {
  Args.getSolidityContractLogTriggerMap().remove(blockNum);
  Args.getSolidityContractEventTriggerMap().remove(blockNum);
}

[xxo1shine]

Enabling only isContractLogTriggerEnable = true and isContractLogTriggerRedundancy = true will not write data; only enabling the solid event switch will write data.

[0xbigapple]

[SHOULD] switchFork has two applyBlock failure paths that don't clear the cache.

[xxo1shine]

Repeated chain switching is a historical oversight and will not be addressed in this PR. It can be discussed separately in a later issue.

[0xbigapple]

[SHOULD] logger.warn loses stack trace; trigger failures will be undebuggable.

Suggestion:

} catch (Throwable throwable) {
  logger.warn("Post contract trigger failed.", throwable);
}

[xxo1shine]

ok

[0xbigapple]

[NIT] testReOrgContractTriggerClearsMap doesn't actually call reOrgContractTrigger — the name is misleading

[xxo1shine]

@0xbigapple, you're right. The test name promises the reorg path but only exercises clearSolidityContractTriggerCache, which also overlaps with testClearSolidityContractTriggerCache below. I'll rewrite this case to actually go through reOrgContractTrigger (construct a forked block and assert the corresponding entry is removed from the cache) so the name and behavior line up.

[yanghang8612]

LGTM