fix(walletconnect): centralize connection and retry logic

[shamardy]

This PR fixes a critical race condition in the WalletConnect module that causes Client(WebsocketClient(NotConnected)) errors during initialization, particularly for the wc_new_connection RPC call.

The Problem

As reported in #2505, network operations could be attempted before the WebSocket connection was fully established or immediately after it was dropped. This resulted in an immediate failure with the following error, instead of returning a valid session URL:

{
    "error": "Subscription Error: Client(WebsocketClient(NotConnected))",
    "error_type": "SessionRequestError"
}

This was a regression traced back to recent changes in #2485 that decoupled WalletConnect initialization from KDF initialization.

The Solution

This PR resolves the issue by refactoring the connection management logic into a robust, centralized state machine. The scattered, per-function retry loops have been removed in favor of a more reliable architecture.

The key changes are:

1. Centralized connection_lifecycle_task: A single background task now owns the entire connection lifecycle. It is the single source of truth for the connection status and handles initial connection, monitoring for disconnects, and reconnection with exponential backoff.

2. State Broadcast via watch Channel: The lifecycle task broadcasts the current connection status (Connecting, Connected, Disconnected) to the rest of the application using a tokio::sync::watch channel.

3. await_connection Gatekeeper: All network-dependent functions (like publish_payload, new_connection, etc.) now first call the await_connection helper. This function acts as a gatekeeper, pausing execution until it receives a Connected signal from the lifecycle task.

This new architecture completely eliminates the race condition by ensuring that no network operation can be attempted unless the connection is confirmed to be active. This makes the connection handling more resilient and easier to maintain.

Fixes #2505

[smk762]

LGTM!

I had a temporary error like

{
    "mmrpc": "2.0",
    "error": "Client Error: failed to connect",
    "error_path": "new_connection.lib",
    "error_trace": "new_connection:29] lib:236]",
    "error_type": "SessionRequestError",
    "error_data": "Client Error: failed to connect",
    "id": null
}

before getting the expected responses a couple of minutes later. I believe this was a local issue, and the fix is working as intended, so ✅

[smk762]

Although I am now able to create a connection, I'm not sure I am able to use it correctly.

A few attempts to connect with scanning QR code with Trust wallet failed.

kdf-1  | 27 10:47:22, kdf_walletconnect:451] INFO [8c46238e5da8cad21c92dc7105f836b4938e8b46c3cb00c29b45c27931e343ce] Publishing message=Request(Request { id: MessageId(448261438189834), jsonrpc: "2.0", params: SessionRequest(SessionRequestRequest { request: Request { method: "personal_sign", params: Array [String("0x41757468656e7469636174652077697468204b4446"), String("0xf5c6738ff36b62a032d11c4badeebf088db58e70")], expiry: None }, chain_id: "eip155:1" }) })
kdf-1  | 27 10:47:23, kdf_walletconnect:472] INFO [8c46238e5da8cad21c92dc7105f836b4938e8b46c3cb00c29b45c27931e343ce] Message published successfully
kdf-1  | 27 10:47:24, kdf_walletconnect:323] INFO [8c46238e5da8cad21c92dc7105f836b4938e8b46c3cb00c29b45c27931e343ce] Inbound message payload={"id":448261438189834,"jsonrpc":"2.0","error":{"code":5300,"message":"Invalid Session Properties requested"}}

I did have a successful attempt with ATOM on Keplr though, so might be just a Trust wallet issue. I'll test a few more.

[smk762]

Confirmed functioning for both EVM and Tendermint, via keplr and metamask wallets.
Had some problems trying to connect with Trust Wallet and Bifrost (which appears to require tesstnet / dev mode).

Tested all wc_methods on legacy/hd/wasm/native and related activations with priv_key_policy using the new object structure

        "priv_key_policy": {
            "type": "WalletConnect",
            "params": {
                "session_topic": "45e250e14bec044dde7b007165608952032421387e6ac36e05654cd1fd175a99"
            }
        }

Some secondary methods to check balance / tx_history were also confirmed to be reporting as expected.

[mariocynicys]

Thanks for the fix.
LGTM!