ioctl: derive EVM chain id from RPC instead of a hardcoded mapping

[envestcc]

Context

PR #4837 adds EIP-7702 SetCode tx support to ioctl. Signing an eth-style tx requires the EVM chain id (a.k.a. evmNetworkID), which differs from the iotex chainID.

Currently ioctl/cmd/action/actioneth.go resolves it with a hardcoded mapping:

iotex chainID 1 -> evmNetworkID 4689   (mainnet)
iotex chainID 2 -> evmNetworkID 4690   (testnet)
iotex chainID 3 -> evmNetworkID 4691   (nightly / local-dev)

with a --evm-chain-id flag as an override for any other chain.

Problem

Hardcoding network parameters is fragile — a chain with a different mapping would produce signatures that don't verify. Review feedback on PR #4837 asked for the value to come from the node instead.

Investigation: the gRPC APIService has no method that exposes evmNetworkID. GetChainMeta returns only the iotex ChainID; GetServerMeta returns version strings only. The single RPC surface that exposes the EVM chain id today is the Web3 JSON-RPC eth_chainId, which ioctl is not configured to reach (ioctl uses the gRPC endpoint).

Proposed follow-up

Preferred: add an evmNetworkID field to the ChainMeta message in iotex-proto and populate it server-side in coreService.GetChainMeta (the node already knows it via bc.EvmNetworkID()). ioctl can then query it and fall back to the existing mapping/--evm-chain-id override when the field is absent (older nodes).

Alternative: teach ioctl to reach a Web3 endpoint and call eth_chainId.

Acceptance

• ioctl no longer hardcodes the iotex→EVM chain id mapping for the common networks
• --evm-chain-id override remains as an escape hatch
• Graceful fallback when talking to a node that doesn't report evmNetworkID