Chain ID included in events

[matthew1001]

There are cases where it is useful to identify which EVM chain an event has been published from:

1. A web socket application may be connected to multiple FF namespaces and be receiving events from multiple underlying blockchains
2. A web socket application may be connected to a single FF namespace, but that FF namespace is then recreated with a different name but using the same underlying blockchain

An application could bind FF namespace to a given chain, but this can be brittle as per 2 above.

An application could also assume that for a given contract address the events must be coming from a given chain. But since contract address is a function of sending account and nonce, a contract address can be identical across different chains.

Below is an example blockchain_event_received received through FireFly with this PR in place:

{
    "id": "4c648899-60ab-4afd-b3e7-6aac78a8df3d",
    "sequence": 75,
    "type": "blockchain_event_received",
    "namespace": "default",
    "reference": "66a65b0b-a58f-4bc7-9fc4-e19cf517fdb0",
    "topic": "test2",
    "created": "2025-04-04T09:10:37.300099174Z",
    "blockchainEvent": {
        "id": "66a65b0b-a58f-4bc7-9fc4-e19cf517fdb0",
        "source": "ethereum",
        "namespace": "default",
        "name": "ValueChanged",
        "listener": "f2e1f912-40a0-46db-9b22-81bfd9cd8bb5",
        "protocolId": "000000000025/000000/000000",
        "output": {
            "newValue": "1223443635445"
        },
        "info": {
            "address": "0x3550a858347c784694ad398f6864afe8f39742a6",
            "blockHash": "0xfced1ea30dca36cf2c888de2e847cc7010a1a314d21731db2ca9551be6ed4b01",
            "blockNumber": "25",
            "chainId": "2021",                              <<--  chain ID from the underlying blockchain
            "listenerId": "0195fb57-ceb1-1fa3-6e97-00d7018ddb74",
            "listenerName": "ff-sub-default-f2e1f912-40a0-46db-9b22-81bfd9cd8bb5",
            "listenerType": "events",
            "logIndex": "0",
            "removed": false,
            "signature": "ValueChanged(uint256)",
            "streamId": "0195dcd5-6714-fce7-0f38-d5e3cc7e99a7",
            "subId": "0195fb57-ceb1-1fa3-6e97-00d7018ddb74",
            "timestamp": "2025-04-04T09:10:36Z",
            "topics": [
                "0x93fe6d397c74fdf1402a8b72e47b68512f0510d7b98a4bc4cbdf6ac7108b3c59"
            ],
            "transactionHash": "0xd3c821f3941a214f05e773ed217ec6b42a7c1e41ecbdf33c1022983f96f2e7ab",
            "transactionIndex": "0"
        },
        "timestamp": "2025-04-04T09:10:36Z",
        "tx": {
            "blockchainId": "0xd3c821f3941a214f05e773ed217ec6b42a7c1e41ecbdf33c1022983f96f2e7ab"
        }
    },
    "subscription": {
        "id": "87bb2b9e-ef09-4bb9-9382-415bc5137575",
        "namespace": "default",
        "name": "87bb2b9e-ef09-4bb9-9382-415bc5137575"
    }
}

This PR adds chainId to the info payload provided by evmconnect. Other connectors could choose to include the same field. It's possible that FF would benefit from it being elevated to a first-class FF event field. Since that is a wider-reaching change I've gone with the smaller change of including it in evmconnect-specific form for now. This doesn't prevent it being added to the main blockchainEvent fields in the future.

[EnriqueL8]

LGTM