fix(sdk): reject TLS keys in wallet adapters

[kvinwang]

Problem

The deprecated Python and JavaScript wallet adapters accepted GetTlsKeyResponse. Their legacy conversion read the first 32 bytes of PKCS#8 DER as private-key material. Those bytes are fixed ASN.1 framing for P-256 keys, so different TLS keys produced the same Ethereum and Solana wallets.

Affected adapters:

• Python: to_account, to_account_secure, to_keypair, to_keypair_secure
• JavaScript: toViemAccount, toViemAccountSecure, toKeypair, toKeypairSecure

Fix

Remove the TLS-key-to-wallet path instead of defining a new conversion for a deprecated API:

• adapter signatures now accept only GetKeyResponse
• runtime calls with a TLS-key response fail with TypeError
• GetTlsKeyResponse.as_uint8array() / asUint8Array() remain unchanged
• no PKCS#8 parser or new key-conversion contract is introduced

Applications deriving wallets must use get_key() / getKey().

Security notice

Wallets previously produced by the non-secure TLS-key path use publicly derivable private-key material. Move any assets immediately. Upgrading prevents further derivation but cannot recover existing assets.

Verification

• Python 3.12.3: 10 targeted adapter tests passed
• Python: mypy and Ruff passed
• Node.js: 8 targeted Vitest tests passed
• TypeScript: tsc --noEmit passed