WIF login fails when SDK public-key-hash lookup is non-unique or key data is serialized as hash bytes

[thephez]

Dashnote currently resolves a pasted WIF by calling identities.byPublicKeyHash() and then matching the identity public key data against the full public key bytes. This can fail on testnet when the SDK cannot return a unique identity for the key hash, or when identity key data is serialized as the 20-byte public-key hash instead of the full public key bytes.

Expected behavior:

• Try the normal byPublicKeyHash() lookup first.
• If that misses, fall back to byNonUniquePublicKeyHash().
• Match candidate identity keys against either full public-key bytes or public-key-hash bytes.
• Preserve existing validation for disabled keys and incorrect key purpose/security level.
• If multiple candidate identities are valid auth matches, return a clear ambiguous-identity error instead of choosing one.

Acceptance criteria:

• WIF login succeeds when only the non-unique public-key-hash lookup finds the identity.
• WIF login supports hex and base64 encoded public-key-hash key data.
• Multiple valid non-unique matches produce a specific ambiguity error.
• Existing invalid WIF, unknown identity, disabled key, and wrong-purpose cases remain covered by tests.