EVM: Handle coinbase transfers for linked beneficiaries

[mpapierski]

Summary

Adds block.coinbase support for Casper block proposers whose public key is not secp256k1, with the main target being ed25519 validators.

Previously, finalized EVM execution derived the block beneficiary with Address::from_public_key(&proposer).unwrap_or(Address::ZERO). Since Address::from_public_key is intentionally secp256k1-only, ed25519 proposers exposed 0x0000000000000000000000000000000000000000 as block.coinbase, and EVM transfers to block.coinbase could not credit the validator’s Casper account.

This PR introduces a Casper-defined proposer receive alias for non-secp256k1 proposers and prelinks that alias to the proposer’s Casper account before finalized EVM execution.

Behavior

For finalized EVM execution:

• secp256k1 proposers keep the existing Ethereum-native beneficiary address derivation.
• ed25519 and other non-secp256k1 proposers use the last 20 bytes of proposer.to_account_hash() as the EVM block.coinbase address.
• before EVM execution, the node attempts to write:

Key::Evm(EvmAddr::Account(beneficiary)) -> Key::Account(proposer_account_hash)

if an EVM contract transfers value to block.coinbase, the value is credited through the identity link to the proposer account’s main purse.

This means patterns like:

payable(block.coinbase).transfer(msg.value);

credit the ed25519 validator’s Casper account main purse when the block is proposed by that validator and the proposer identity can be safely linked.

Important Caveats

The non-secp256k1 beneficiary address is a Casper-defined receive alias, not an Ethereum key-derived EOA.
It cannot sign Ethereum transactions. Address::from_public_key remains secp256k1-only and keeps its Ethereum-native semantics.

The proposer identity link is created before finalized EVM execution, not lazily during EVM state application. This keeps the EVM executor from creating Key::Account bridges.

Existing EVM identity state is not overwritten:

• if the beneficiary address already has a Key::Account identity, that identity is preserved;
• if it already has a Key::URef identity, that identity is preserved;
• if it has code or nonce but no identity, no proposer link is created;
• invalid or malformed identity state is treated as an execution error.

If an existing linked beneficiary has code, a transfer to block.coinbase follows normal EVM semantics and executes that code.