Desktop blind-retries an oversized (~66KB) frame on join — reconnect storm against relays with the 64KB limit

## Environment

- Relay: `ghcr.io/block/buzz:sha-2d26db6` (frame limit hardcoded
`MAX_FRAME_BYTES = 65536`, `connection.rs:287` at that commit — predates
configurable #1225 / `38a95334…`)
- Desktop: current auto-updated release (0.4.2x era), macOS
- Flow: fresh **join** of a new community on a fresh relay (NIP-42 auth on,
membership enforcement on)

## What happens

Immediately after a successful join, the desktop publishes a text frame of
**66,155 bytes** — just over the relay's 65,536 limit. The relay (correctly)
drops the connection; the desktop reconnects and **immediately retries the
same frame**, several times per second, indefinitely:

```
WS established → NIP-42 auth successful → WARN frame too large — disconnecting (bytes=66155) → WS closed → …repeat ~3-4×/sec
```

The app looks *completely healthy* to the user — chat works between retries —
so the storm burns relay CPU, LB traffic and client battery invisibly. On our
LB-fronted deployment it also generated a steady churn of new connections.

Bumping the relay to a #1225-capable image and setting
`BUZZ_MAX_FRAME_BYTES=262144` stopped it (confirmed zero drops after).

## Issues to consider (independent)

1. **Client should respect the advertised limit**: the relay serves
`limitation.max_message_length` in NIP-11; the client sends 66,155 bytes
against an advertised 65,536 and treats the resulting disconnect as a
transient network error.
2. **No backoff on this failure class**: same payload, immediate retry,
forever. Even without NIP-11 awareness, a disconnect immediately after
sending frame X should not re-send X at full speed — cap retries or
back off exponentially.
3. **What is the ~66KB event?** It's deterministic on fresh join (same
66,155 bytes every attempt for this identity). If a first-join payload can
exceed the relay's own default limit, either the payload should be chunked
or the default limit reconsidered. Happy to help capture it — we can
reproduce at will.
4. Optionally: relay could send a NIP-01 `NOTICE`/`OK false` with a
machine-readable "too large" before closing, giving clients something
better than a bare disconnect to react to.