New chat UI hangs when native_relay_client archive:owner_p is rate-limited

[toor-1970]

Important

No secrets, keys, or host identifiers in this report.

Describe the bug

Desktop 0.5.20 new-chat / new message entries stall when native_relay_client hits relay archive quota:

native_relay_client: relay closed archive:owner_p:<owner>:24200,44200: rate-limited: quota exceeded; retry in 4s
native_relay_client: relay closed archive:owner_p:<owner>:24200,44200: rate-limited: quota exceeded; retry in 0s

The relay itself is up (/_liveness ok; CLI channels list works). The UI appears frozen because new chats wait on that archive backfill (kinds 24200/44200). Retry-in-0s does not recover the composer.

This stacked with Share restore warmup (separate issue: short catalog modelId 404) on a Tight-fit Share host, where UI and MeshLLM share one buzz-desktop process.

Steps to reproduce

1. Join a closed relay, use Desktop for a long sitting (many messages / media / agent turns).
2. Open a new chat or send a new entry when stdout shows archive:owner_p rate-limited: quota exceeded.
3. Observe the composer/new-chat path hang. CLI against the same relay still works.

Expected behavior

• Archive quota should not block creating or sending in a new chat (backoff in the background, fail the backfill, or surface a retry — not freeze the thread).
• retry in 0s should not spin the UI.

Version and platform

• Buzz version: 0.5.20
• OS: macOS

Logs / additional context
Owner pubkey omitted. Filter is archive:owner_p:…:24200,44200.