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

**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 `), 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 ` 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 `.
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.