Relay DNS failure

**Describe the bug**

Buzz Desktop did not recover its relay connection after a VPN/network change. With the VPN enabled, Buzz could not reach the relay. Disabling the VPN did not restore connectivity. Restarting Buzz immediately restored operation.

This suggests that the desktop client retained a stale DNS/WebSocket connection or failed to re-resolve and reconnect after the network path changed.

**Steps to reproduce**

1. Start Buzz Desktop and connect to a Buzz relay.
2. Enable a VPN and allow the network path or DNS configuration to change.
3. Observe that Buzz can no longer reach the relay.
4. Disable the VPN.
5. Observe that Buzz still cannot reach the relay or messages remain stale.
6. Restart Buzz Desktop.
7. Observe that connectivity is restored.

**Expected behavior**

Buzz should detect VPN, interface, DNS, or connectivity changes and automatically re-resolve the relay hostname, reconnect its WebSocket/session, and refresh message delivery. If reconnection is not possible, the UI should show a clear disconnected state and provide a retry action.

**Version and platform**

- Buzz version: 0.5.5
- OS: macOS 26.6 (Build 25G72)
- VPN vendor: unknown
- Relay: `wss://xxxx.communities.buzz.xyz`
- Incident date: 2026-08-06

**Logs / additional context**

- The observed connection error was:

`error sending request for url (https://xxx.communities.buzz.xyz/query): client error (Connect): dns error: failed to lookup address information: nodename nor servname provided, or not known`

- No Buzz crash report or dedicated local Buzz log was found in the inspected locations.
- Because Buzz was restarted before inspection, pre-restart client logs were not available.
- After restart, the relay hostname resolved and authenticated message reads succeeded.
- Restarting Buzz is the current workaround.

Please investigate reconnection after VPN disconnect, network-interface changes, DNS recovery, and restored internet connectivity. The client should not require a full restart to recover from a transient network-path change.

Start by reproducing the VPN and network-interface transition described in the issue, then trace the desktop relay DNS and WebSocket/session reconnection path using the reported DNS error. Done means the client re-resolves the relay and restores message delivery without a restart, or shows a disconnected state with a retry action when recovery fails.

Written by the indexing model from the issue text.