Self-hosted relay: agent's first profile publish (kind:0) gets 403 relay_membership_required, client never retries after membership resolves

[uwebeyond]

Environment

• Buzz Desktop 0.5.2 (macOS)
• Self-hosted relay, image ghcr.io/block/buzz:main
• Relay config: BUZZ_REQUIRE_RELAY_MEMBERSHIP=true

Steps to reproduce

1. Self-host a relay with BUZZ_REQUIRE_RELAY_MEMBERSHIP=true
2. Create a new agent in Buzz Desktop against a community on that relay
3. "Agent created" dialog shows:
   "Could not sync the agent's profile metadata: relay returned 403
   Forbidden: You must be a relay member to access this relay"

What I verified directly against the relay's own Postgres DB

• relay log: WARN "not a relay member" for the new pubkey at T,
  403 error.code=relay_membership_required
• relay_members row for that exact pubkey inserted at T+~130ms–1s
  (added_by='-', no audit_log entry — looks like an internal/automatic
  grant, not an admin action)
• events table: zero kind:0 events for that pubkey, checked minutes
  later — the client never retried the profile publish after the 403,
  even though membership existed within about a second.

Reproduced twice independently with two different pubkeys/timestamps,
same pattern both times.

Question

Should the desktop client retry the initial agent-identity publish
after a 403 relay_membership_required, given membership appears to
resolve asynchronously within ~1s of the same connection attempt?

Related issues

This looks adjacent to a cluster of currently-open self-hosted-relay
membership/timing issues, but distinct from all of them (this one is
specifically the very first kind:0 publish for a brand-new pubkey,
before any membership row exists yet):

• Intermittent 403 on POST /events (HTTP bridge) causes buzz-agent deadlock #2936 — Intermittent 403 on POST /events (HTTP bridge) causes
  buzz-agent deadlock — author independently asks "is this a
  membership cache race?"
• Closed-relay production defaults lock the desktop out of its own relay — no invite/token-mint path exists #2969 — Closed-relay production defaults lock the desktop out of
  its own relay
• Agents show RUNNING/online but never respond — no channel subscriptions resolved, empty harness log (self-hosted, macOS) #2641 — Agents show RUNNING/online but never respond — no channel
  subscriptions resolved
• Desktop v0.5.2 shows relay owner as non-member despite active channel_members row #3796 — Desktop v0.5.2 shows relay owner as non-member despite
  active channel_members row

[iroiro147]

Opened PR #4088 with a fix.

Root cause confirmed: on a self-hosted closed relay (BUZZ_REQUIRE_RELAY_MEMBERSHIP=true), the automatic relay_members grant lands asynchronously (~130 ms–1 s after first connect per your Postgres evidence), so the desktop client's first kind:0 profile publish races the grant and gets a 403 relay_membership_required. The desktop client always treated that 403 as terminal and never retried.

Fix: sync_managed_agent_profile in desktop/src-tauri/src/relay.rs now retries the publish exactly once after 500 ms, only when the 403 body contains relay_membership_required. All other failures behave exactly as before, and a truly non-member agent still errors the same way (just ~500 ms slower on first attempt). Since the retry lives inside the shared sync helper, every caller of profile sync gets the fix with no other changes.

Verification: 4 new unit tests for the error-summarization helper, existing ncryptsec boundary test still green, cargo check/clippy/test --lib all pass. Not E2E-vs-real-relay (needs two-pod closed relay), and the retry is gated on the exact body shape the relay emits.