feat: implement Waku transport for extension-TUI communication

[mfw78]

What problem does this solve?

Currently, the WebSocket connection requires the TUI (and its connected hardware wallet/Keycard) to run on the same machine as the browser. Users cannot physically separate their hardware wallet and signing device from their browsing device for enhanced security.

Describe the solution

Add Waku messaging as an alternative transport for extension ↔ TUI communication. This allows the TUI with its connected Keycard/hardware wallet to run on a separate, physically isolated machine while the browser with extension runs on the daily-use browsing machine. The devices communicate through Waku's gossip network instead of localhost WebSocket.

Alternatives considered

• Only use localhost WebSocket (requires hardware wallet on same machine as browser)
• Use network WebSocket with TLS (complex key management, direct network connection exposes both devices)
• Use SSH tunneling (requires SSH setup, platform-specific, complex for non-technical users)

Implementation notes

• Abstract transport layer in both extension worker and TUI
• Integrate Waku as alternative transport implementation alongside WebSocket
• Design secure session establishment and authentication over Waku
• Handle latency gracefully (gossip is slower than localhost)
• Allow user to choose transport: WebSocket (local) or Waku (remote)
• Add pairing mechanism for extension and TUI to discover each other on Waku network
• Ensure strong encryption and authentication for remote signing requests
• Consider bandwidth implications for high-frequency RPC calls
• Document security model for physical separation use case