Agent needs explicit relay membership + harness restart to be discovered in a new channel, even with BUZZ_REQUIRE_RELAY_MEMBERSHIP=false

[guilherme-fish-dev]

Describe the bug
Split out from #5446 per @kiranmagic7's review — this is a distinct boundary from the ACP delivery gap tracked in #2698.

An agent added to a channel does not reliably become "live" in that channel until two extra steps happen, neither of which is obvious from the UI:

1. The agent's pubkey must be an explicit relay member (buzz-admin add-member <pubkey>), even when the relay is configured with BUZZ_REQUIRE_RELAY_MEMBERSHIP=false. Without it, the first turn in a channel fails outright with:

   Turn error · error: Community access denied this agent — check its community membership.
   

2. Even after relay membership is granted, an agent added to a channel (via the "Create agent" / "Add people" desktop UI) does not pick up that channel if it was added while the agent's harness was already running — channel discovery only seems to run reliably at harness startup. A manual restart of the agent (stop/start) is required for it to "discover N channel(s)" and start responding there.

Both steps had to be done manually via buzz-admin/the desktop restart button; there's no error or guidance surfaced anywhere in the UI pointing at either cause. From the user's side, the agent just looks "online" and never responds, which reads as "broken" rather than "needs one more step."

Steps to reproduce

1. Self-host the relay (deploy/compose/), BUZZ_REQUIRE_RELAY_MEMBERSHIP=false.
2. Create a new channel via the desktop app, adding a brand-new agent to it via "Create agent" at channel-creation time.
3. Mention the agent. First turn fails with Community access denied this agent.
4. Run buzz-admin add-member <agent-pubkey> to add it as a relay member.
5. Mention the agent again in the same channel. Still no response — harness log shows discovered 0 channel(s) / no channel subscriptions resolved — agent will sit idle from before the membership fix.
6. Manually restart the agent (stop, then start) from the desktop app.
7. Mention the agent again — now it responds normally, harness log shows discovered N channel(s) and subscribed to channel <uuid>.
8. Repeating steps 2–7 for a second new channel with the same (already relay-member) agent reproduces the same "silent until restart" behavior — so it's tied to per-channel discovery timing, not solely relay membership.

Expected behavior

• If BUZZ_REQUIRE_RELAY_MEMBERSHIP=false, an agent shouldn't need an explicit relay-member row to pass a per-community access check — or if that check is intentional regardless of the flag, the UI/CLI flow for adding an agent to a channel should also grant relay membership automatically.
• Channel membership added while an agent's harness is already running should be picked up without requiring a manual restart — or, short of live re-resolution, the UI should surface a clear "restart required to pick up new channel" prompt instead of leaving the agent looking silently idle/online.

Version and platform

• Buzz: built from source, main branch, self-hosted via deploy/compose/
• OS: Windows 11
• Harness: native Buzz Agent

Logs / additional context
Happy to provide the full harness log sequence (relay-membership denial → add-member → still-idle discovery → restart → success) on request.

[jaozolins]

Also self-hosting (compose / VPS). Same pain when adding agents to new channels:

Agent looks online, mentions do nothing, no clear UI guidance. Fix path for us has been: explicit relay membership + restart harness so it rediscovers channels — even when membership-required is off.

Anything that auto-grants membership on “add to channel” and/or picks up new channels without a full restart would remove a lot of silent “is it broken?” moments.