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.

Fixes #6678

Why are these changes required?

This PR has been tested by:

• Unit Tests
• Manual Testing

Follow up

Extra details