[bug] Sign message, either through `wagmi` or direct `personal_sign` RPC call, produces invalid signature

[target-san]

Link to minimal reproducible example

https://gist.github.com/target-san/4aae9f437a0d74af771447a68987cec5

Steps to Reproduce

1. Create starter reown-appkit application with wagmi using @reown/appkit-cli
2. Login to social profile via Google. Not sure if social login method amtters.
3. Use "Sign Msg" button to get signature for default "Hello Reown AppKit!" message. Though I got some result when using direct "personal_sign" RPC method.

Summary

Expected: payload produced by signMessageAsync can be parsed as ERC-6492 payload. I.e. factory address, factory calldata and 65-byte SECP256K1 message (?) signature

Actual: last bytes block can't be parsed as signature - recovery byte 0x20 is not a correct recovery byte.

Details:
The gist provided is in Rust. It contains smart wallet address on which this issue reproduces, message being signed and actual signed message payload.

Can't imagine what else I can provide since sample app is completely generated by CLI tool, and produces such results out of the box. Can't also give exact social login because it was one of my secondary emails.

P.S: I've been getting other cases of invalid parity bytes, like 31

List of related npm package versions

  "dependencies": {
    "@reown/appkit": "1.7.17",
    "@reown/appkit-adapter-wagmi": "1.7.17",
    "@tanstack/react-query": "^5.56.2",
    "react": "19.0.0",
    "react-dom": "19.0.0",
    "viem": "^2.31.7",
    "wagmi": "^2.15.6"
  },
  "devDependencies": {
    "@eslint/js": "^9.9.0",
    "@types/react": "^19.0.10",
    "@types/react-dom": "^19.0.4",
    "@vitejs/plugin-react": "^4.3.1",
    "eslint": "^9.9.0",
    "eslint-plugin-react-hooks": "^5.1.0-rc.0",
    "eslint-plugin-react-refresh": "^0.4.9",
    "globals": "^16.0.0",
    "typescript": "^5.5.3",
    "typescript-eslint": "^8.0.1",
    "vite": "^6.2.0"
  }

Node.js Version

v20.10.0

Package Manager

npm@10.2.5

[linear]

APKT-3569 [bug] Sign message, either through `wagmi` or direct `personal_sign` RPC call, produces invalid signature