fix(storage): hash the map key in storage get --key - #180

Summary

quantus storage get --pallet <P> --name <N> --key <K> --key-type <T> builds the storage key as twox128(P) ++ twox128(N) ++ encode(K). It never applies the map's hasher. For System::Account (Blake2_128Concat), the example in the --key help text, the resulting key does not exist, so the command always prints "No value found". (#27 worked around this by passing a hand-built --storage-key.)

This PR looks up the entry's hasher in the live metadata and applies it to the encoded key (all seven StorageHasher variants). Using --key on a plain value, or on a map with more than one key, now returns a clear error instead of silently querying a key that does not exist.

Before (key built by the CLI) vs. what subxt's codegen produces for System::Account([7; 32]):

cli:     26aa394eea5630e07c48ae0c9558cef7b99d880ec681799c0cf30e8886371da9 0707…07
codegen: 26aa394eea5630e07c48ae0c9558cef7b99d880ec681799c0cf30e8886371da9 ddd6249d8a7334cf5ea37d21811e6671 0707…07

Testing

• Added storage_map_key_matches_codegen_for_system_account, which compares against get_address_bytes for the generated System::Account address using the checked-in metadata, and storage_map_key_rejects_plain_storage_value. Both fail on main and pass with this change.
• cargo test --lib, cargo clippy --all-targets -- -D warnings, cargo +nightly-2026-08-31 fmt --check. The only test failure is batch_verifier::loads_private_and_public_batch_verifiers, which needs generated circuit bins that I skipped with SKIP_CIRCUIT_BUILD=1.

I used an AI assistant (Claude) while preparing this. I reproduced the issue and checked the fix and tests myself.

🤖 Generated with Claude Code