WalletConnect v1 session collision when connecting multiple wallets

[drichar]

Bug Description

The library fails to properly manage WalletConnect sessions when connecting a second WalletConnect v1-based wallet (e.g., Defly) while another (e.g., Pera) is already connected. This issue stems from WalletConnect v1's use of a non-unique local storage key (walletconnect), causing a collision when attempting to connect multiple wallets.

Expected Behavior

Users should be able to connect multiple wallet providers simultaneously, including multiple WalletConnect-based wallets (e.g., Pera and Defly), without errors or inconsistent states.

Current Behavior

Attempting to connect a second WalletConnect-based wallet while another is connected results in:

1. An error in the console: DeflyWalletConnectError: Session currently connected
2. The second wallet failing to connect on the first attempt
3. Inconsistent wallet states even if the connection succeeds on a second attempt
4. Possible failure of transaction signing due to invalid wallet states

Reproduction

1. Connect to Pera wallet
2. Without disconnecting Pera, attempt to connect to Defly
3. Observe the error in the console and the failure to connect
4. Attempt to connect with Defly again
5. Connection may succeed, but the wallets will be in an invalid state and transaction signing may fail

Environment

• @txnlab/use-wallet version: 3.6.0

Suggested Solution

Implement a new method in the Pera (v1) and Defly provider classes to be called at the beginning of the connect process:

1. Check if another WalletConnect-based wallet is currently active
2. If so, backup its session data in a unique local storage key
3. Clear the existing walletconnect key
4. Proceed with connecting the new wallet

When setting Pera (v1) or Defly as active:

1. Check if another WalletConnect-based wallet is currently active
2. If so, backup its session data in a unique local storage key
3. Restore the backup session data for the new active wallet
4. Proceed with setting the wallet as active