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

## 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):

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

Trace the desktop client's initial kind:0 publish and its handling of the relay_membership_required 403; reproduce with BUZZ_REQUIRE_RELAY_MEMBERSHIP=true and inspect the relay_members row and events table timing. Done means a new agent's profile publish succeeds after membership resolves and a kind:0 event appears without manual intervention.

Written by the indexing model from the issue text.