fix tagged keys used in signMessage

[mak1986]

https://github.com/Panda-Wallet/panda-wallet/issues/190

[mak1986]

I encountered an issue with signature verification in the backend using the bsv library. The verification process involved checking a message against the identity address received from the frontend. The relevant code snippets are provided below:

Frontend:

            const addresses = await wallet.getAddresses();
            const pubKeys = await wallet.getPubKeys();
            const profile = await wallet.getSocialProfile();

            const message = {
                message: 'Login time - ' + moment(Date.now()).utc().format('MMMM DD, YYYY HH:mm:ss [UTC]'),
                encoding: 'utf8'
            } as SignMessage
            const signedMessageResponse = await wallet.signMessage(message)!

            const payload = {
                displayName: profile?.displayName,
                avatar: profile?.avatar,
                bsvAddress: addresses?.bsvAddress,
                identityAddress: addresses?.identityAddress,
                ordAddress: addresses?.ordAddress,
                bsvPubKey: pubKeys?.bsvPubKey,
                ordPubKey: pubKeys?.ordPubKey,
                identityPubKey: pubKeys?.identityPubKey,
                m: signedMessageResponse?.message,
                s: signedMessageResponse?.sig
            }

            const res = await UserService.authenticate(payload)

Backend:

const {identityAddress, m, s} = payload
const valid = bsv.Message.verify(Buffer.from(m, 'utf8'), bsv.Address(identityAddress), s);

The verification fails, and the reason is that the code snippet from the keys.ts file is never executed during the signMessage call:

  if (tag.label === 'panda') {
    switch (tag.id) {
      case 'bsv':
        return PrivateKey.from_wif(keys.walletWif);
      case 'ord':
        return PrivateKey.from_wif(keys.ordWif);
      case 'identity':
        return PrivateKey.from_wif(keys.identityWif);
      default:
        return PrivateKey.from_wif(keys.identityWif);
    }
  }

Basically, the signature is using another identity keys.

[danwag06]

@shruggr would you mind looking at this when you have a second? I'm hesitant to make the call as I'm not 100% this doesn't break other things.