feat(wallet): derive PrivateKey/Wallet from BIP-39 mnemonic

[ozpool]

Summary

Closes #297. Two community members have asked for an in-tree way to recover a Solana key from a mnemonic. Today every consumer rolls their own combination of a BIP-39 library and SLIP-0010 derivation, with the extra friction that BIP-32 is secp256k1-only and does not apply to ed25519.

This adds:

• PrivateKeyFromMnemonic(mnemonic, passphrase) — uses the Phantom default path m/44'/501'/0'/0'
• PrivateKeyFromMnemonicAtPath(mnemonic, passphrase, path) — custom SLIP-0010 path
• PrivateKeyFromSeedAtPath(seed, path) — for callers that already have their own seed bytes
• NewWalletFromMnemonic(mnemonic, passphrase) — convenience wrapper around the existing Wallet type
• SolanaDerivationPath constant ("m/44'/501'/0'/0'")

Design notes

• Mnemonic → seed: uses github.com/tyler-smith/go-bip39 (the de facto Go BIP-39 implementation, also used by btcsuite/btcd/btcutil/hdkeychain and Cosmos SDK forks). Single new direct dependency.
• Seed → ed25519 key: in-tree SLIP-0010 implementation. SLIP-0010 ed25519 only defines hardened derivation and is small enough (~40 LOC) not to warrant pulling in a generic HD-key library.
• Final seed → keypair: goes through the existing oasisprotocol/curve25519-voi ed25519, so the result is bit-identical to NewRandomPrivateKey output and works with the existing Sign / Validate / PublicKey methods unchanged.
• All existing public API is untouched; this is purely additive.

Test plan

• Official SLIP-0010 ed25519 vectors from satoshilabs/slips:
  • vector 1: m, m/0', m/0'/1', m/0'/1'/2', m/0'/1'/2'/2', m/0'/1'/2'/2'/1000000000'
  • vector 2: m, m/0'
• Derivation-path parsing (empty / default / h / H / ' suffixes, non-hardened rejection, malformed input)
• Mnemonic validation, determinism, passphrase sensitivity, path sensitivity
• End-to-end Sign/Verify against the derived key
• go vet ./... (only pre-existing warnings in rpc/ws/examples/...)
• gofmt -l clean
• Full root-package test suite passes