Desktop agent launcher reuses another community's agent identity, causing "restricted: not a relay member" on self-hosted relays

## Environment

- Buzz Desktop v0.5.7 (macOS, aarch64)
- Relay v0.2.0 (`ghcr.io/block/buzz:main`), two self-hosted closed relays via `deploy/compose`
- Desktop connected to three communities: two self-hosted relays plus one `*.communities.buzz.xyz` hosted community

## Summary

With multiple communities configured, the desktop's managed-agent launcher selects which agent identity (keypair) to launch **by agent name**, not by (name, community). It repeatedly launched the *hosted community's* Fizz and Honey keypairs against both self-hosted relays. Closed relays correctly reject the foreign pubkey, so the agents die with:

```
WARN buzz_acp::relay: initial relay connect failed with terminal error: Auth failed: restricted: not a relay member
Error: relay connect error: Auth failed: restricted: not a relay member
```

and the UI shows `harness exited with status exit status: 1`.

## Evidence

`managed-agents.json` correctly holds one entry per (name, relay_url), each with its own pubkey — the registry itself is fine:

```
Bumble wss:// pubkey b9566191…
Bumble wss:// pubkey 34b6d4ac…
Bumble wss://.communities.buzz.xyz pubkey dbe71ddb…
Fizz wss:// pubkey d22e491c…
Fizz wss:// pubkey 960870f6…
Fizz wss://.communities.buzz.xyz pubkey 64ecfde7…
Honey … (same pattern)
```

But the per-agent log files (`agents/logs/__.log`) show the launcher crossing them:

- `64ecfde7…__.log` — the **hosted** community's Fizz pubkey, connecting to `wss://` → rejected, "not a relay member"
- `1d4fcaa7…__.log` — the hosted community's Honey pubkey, same rejection
- Later the *same two hosted-community pubkeys* were launched against self-hosted relay B (`…__.log`) with the same failure

Meanwhile the correct per-relay identities (`d22e491c`, `e1db22b5`, …) sat unused. Which agent "works" is effectively selection-order luck — in our case Bumble happened to keep a valid pairing while Fizz/Honey did not.

## Repro (as observed)

1. Join/configure ≥2 communities in the desktop, each with the default managed agents (distinct keypairs per community are created correctly).
2. Restart agents for community A (e.g. after a relay-side reset, or plain stop/start).
3. Launcher starts `buzz-acp` for community A using an identity belonging to community C; closed relay A rejects it.

## Expected

Agent launch resolves the managed-agent entry by **(name, community/relay_url)** — never by name alone — so each community's agent always authenticates with that community's keypair.

## Workarounds used

- Enrolling the foreign pubkeys as members on the self-hosted relays (makes the misrouted agents connect, but wrong identities then act in the community), or
- Deleting the other community's agent entries from `managed-agents.json` so only correct candidates remain.

## Related observation

An agent created without a `relay_url` (unscoped) is listed in **every** community's agent view. If unscoped entries are intended as templates only, hiding them from community rosters would avoid confusion; if they're launchable, they have the same identity-selection ambiguity as above.

Start with managed-agents.json and the per-agent files under agents/logs, then trace the desktop managed-agent launcher and its buzz-acp entry point to see how identities are selected. Done means launches resolve agents by name and community or relay_url, so a community never starts another community's pubkey against its relay.

Written by the indexing model from the issue text.