fix: use checksum address when derving aptos account from ethreum add…

[zebriot]

when the account changed event was fired on EIP1193, it didnt returned a checksummed address so on account change, the derived aptos wallet was wrong, this fixes it and uses checksum address always

[0xmaayan]

@zebriot thanks for looking at it. I've been investigating the same problem and wanted to share some concerns about this approach.

Backward Compatibility Issue

Using checksumAddress() to normalize Ethereum addresses would be a breaking change. The derived Aptos address is computed using the Ethereum address as input. If existing users derived their accounts using lowercase addresses (e.g., 0xc7b576...), switching to checksummed addresses (0xC7B576...) would produce a completely different derived Aptos address.

This means users would effectively lose access to their existing derived accounts and any funds/assets associated with them.

Root Cause Analysis

I traced the actual bug and found it's not a casing issue. The problem is that the accountsChanged event returns an array of all authorized accounts, but the order is not guaranteed to have the currently selected account first. The previous code was taking [0] from this array, which wasn't always the active account.

On-Chain Evidence

The on-chain authentication function (0x1::ethereum_derivable_account::authenticate) already works without checksummed addresses, confirming the existing derivation logic is correct and doesn't require address normalization.

Alternative Fix

I've opened a PR with a fix that:

1. Ignores the event's accounts array data
2. Queries the active account directly via getActiveAccount() when the event fires
3. Maintains full backward compatibility - no change to how addresses are derived

#705

---