Relay connection unrealiable

`Repeated "Can't reach the relay" errors despite successful WebSocket reconnects`

### Summary

Buzz Desktop repeatedly displays:

> Can't reach the relay

The relay is reachable and WebSocket connections are established successfully, but active agent connections are repeatedly reset. Most agents reconnect automatically, although the desktop UI continues to report relay errors.

### Environment

- Buzz Desktop: 0.5.5
- Relay: `alanrossmachinery.communities.buzz.xyz`
- macOS
- Multiple managed Buzz agents
- Agents use a mixture of:
- Claude ACP
- Codex/OpenAI ACP
- OpenRouter

### Observed behavior

The issue affects agents using different model providers and inference locations. The affected agents include both remote-model agents and an agent using a local model through oMLX.

Representative agent log messages include:

```text
Connection reset without closing handshake
Connection reset by peer
Peer closed connection without TLS close_notify
```

Connections generally recover automatically, often on the first reconnect attempt. However, the desktop application repeatedly displays the generic relay connectivity error.

### Scope

The resets are not isolated to one model provider or one agent. They have been observed across:

- Claude ACP agents
- Codex/OpenAI ACP agents
- OpenRouter agents
- A local oMLX agent

The local-model agent still uses the same remote Buzz relay WebSocket, so the issue appears to be associated with the shared relay connection rather than model inference.

### Connectivity checks

The following checks succeed:

- Relay DNS resolution
- HTTPS health check, returning `200 ok`
- WebSocket upgrade, returning `101 Switching Protocols`
- NIP-11 relay information request
- AUTH challenge from the relay

This suggests that initial connectivity, TLS, and WebSocket negotiation are working. The failure occurs later during the lifetime of the connection.

### Expected behavior

Buzz should maintain stable long-lived relay connections. If a connection is reset, the desktop UI should either:

1. Recover cleanly without displaying a persistent error, or
2. Display which specific connection or agent is affected and provide useful diagnostic information.

### Actual behavior

- Relay connections are repeatedly reset without a normal WebSocket closing handshake.
- Agents reconnect, but the desktop UI continues to show "Can't reach the relay."
- The error does not identify the affected agent or distinguish between an initial connection failure and a transient reconnect.
- The behavior occurs across agents using different model providers and local versus remote inference.

### Troubleshooting performed

- Confirmed relay DNS resolution.
- Confirmed relay HTTPS health endpoint returns `200 ok`.
- Confirmed WebSocket upgrade succeeds with `101 Switching Protocols`.
- Observed the same reset pattern across multiple managed agents.
- Fully restarting Buzz temporarily clears the condition.
- `Cmd+R` can also temporarily refresh the desktop session.
- The issue does not appear specific to OpenRouter, Anthropic, OpenAI, or the local oMLX server.

### Likely area for investigation

Could you please investigate:

- Relay WebSocket edge or proxy resets
- Cloudflare or reverse-proxy idle timeout behavior
- Relay restarts or connection-capacity limits
- Ping/pong forwarding and heartbeat handling
- TLS termination when connections are closed
- Buzz's handling of transient WebSocket resets and reconnect state
- Whether the desktop UI is reporting a stale error after the underlying connection has recovered

The main diagnostic pattern is:

```text
WebSocket connection established
Connection reset without closing handshake
Automatic reconnect succeeds
Desktop still reports "Can't reach the relay"
```
```

Start by reproducing the reset-and-reconnect sequence using the listed DNS, HTTPS, WebSocket, and NIP-11 checks, then compare relay and desktop behavior during the reset. Investigate the WebSocket edge, proxy or heartbeat path and the desktop reconnect state. Done means stable long-lived connections or a cleared, specific diagnostic when a reset occurs.

Written by the indexing model from the issue text.