fix: issue #271 Arbitrum contract shown as account

[josealoha666]

Summary

Fixes false account classification on address pages when type detection RPC calls fail.

Root cause

In src/components/pages/evm/address/index.tsx, the address page:

1. Fetches address data via dataService.networkAdapter.getAddress() (which includes code from eth_getCode)
2. Then calls fetchAddressWithType() to detect the specific type (ERC-20, ERC-721, etc.)

If step 2 failed (RPC error, timeout, etc.), the .catch() handler always fell back to "account" — even when the already-fetched code clearly showed non-empty bytecode, indicating a contract.

This caused contracts on Arbitrum (and potentially other networks) to be displayed as EOA accounts.

Changes

src/utils/addressTypeDetection.ts

• Export hasContractCode() so it can be reused (was previously private)

src/components/pages/evm/address/index.tsx

• Import hasContractCode from the detection utility (no logic duplication)
• In the .catch() fallback: use hasContractCode(addressData.code) to infer type from already-fetched data instead of forcing "account"
• In the no-RPC branch (else): same fallback instead of leaving type as default "account"

src/utils/addressTypeDetection.test.ts (new)

• Unit tests for hasContractCode (null, empty, 0x, 0x0, real bytecode, case sensitivity)
• Unit tests for checkEIP7702Delegation and getEIP7702DelegateAddress
• Unit tests for getAddressTypeLabel and getAddressTypeIcon
• 10 tests, all passing

Verification

• Confirmed via direct RPC calls that eth_getCode for 0xc27F8a94Df88C4f57B09067e07EA6bC11CA47e11 on Arbitrum returns ~33KB of bytecode (definitively a contract)
• Multiple Arbitrum public RPCs tested (1rpc, drpc, fastnode, meowrpc) — all return valid bytecode
• All unit tests pass (vitest run)

Issue

Closes #271

[github-actions]

🚀 Preview: https://pr-272--openscan.netlify.app
📝 Commit: 8bff79148977e8981f77b6721b599bbe0d2f1ef2