Two ways an xprv import could silently produce a wallet that is not the
user's, with no error shown.
Checksum: ethers' HDNodeWallet.fromExtendedKey skips base58 checksum
verification when the decoded payload is the usual 82 bytes, which is
exactly the case the checksum exists to catch. Every extended key now
goes through parseExtendedKey, which re-encodes the parsed node and
requires the round trip to reproduce the input exactly. Over every
single-character substitution of the BIP-32 vector 1 master key, 199
parsed before and 0 parse now; the xpub path shared the hole (101
accepted typos) and is fixed by the same helper.
Depth: hdWalletFromXprv and getSignerForAddress derived the relative
path 44'/60'/0'/0, which is the BIP-44 Ethereum account path only for a
depth-0 master key. Under an account-level (depth-3) key it derived
m/44'/60'/0'/44'/60'/0'/0 instead of refusing. Both now derive the
absolute BIP44_ETH_PATH from a key checked to be at depth 0. The
extended-key format carries depth, parent fingerprint and child index
but not the path a key sits at, so a non-master key cannot be placed in
the tree without guessing; it is rejected, and the import screen says
an account-level or child key is not supported.
Import errors are full sentences per the README Language & Labeling
rules, and the skipped one-character-typo test is unskipped.
