Local dev: loopback hosts are seeded as separate communities, so desktop-managed agents silently discover 0 channels

## Summary

In local dev, `scripts/seed-local-community.sh` seeds `localhost:3000` and `127.0.0.1:3000` as **separate rows in `communities`** — i.e. two isolated tenants — while the desktop app connects as `ws://localhost:3000` but spawns managed-agent harnesses with the **canonicalized** URL `ws://127.0.0.1:3000`. The result: every desktop-managed agent lands in an empty tenant, discovers 0 channels, and silently never responds to mentions. This cost us several hours to debug, because nothing errors — the agents just sit idle.

## Environment

- macOS, current `main` (`6f19a18` era), `just setup` + `just dev`
- Default `.env` (`RELAY_URL=ws://localhost:3000`), default `scripts/instance-env.sh` (`BUZZ_RELAY_URL="${BUZZ_RELAY_URL:-ws://localhost:3000}"`)

## Steps to reproduce

1. `just setup` (seeds communities), `just dev`
2. Complete desktop onboarding against `ws://localhost:3000`; create a channel
3. Create a managed agent (e.g. Honey), add it to the channel, start it
4. Mention the agent in the channel

**Expected:** the agent responds.

**Actual:** nothing happens. The harness log (`~/Library/Application Support//agents/logs/__.log`) shows:

```
INFO buzz_acp: buzz-acp starting: relay=ws://127.0.0.1:3000 ...
INFO buzz_acp: discovered 0 channel(s)
WARN buzz_acp: no channel subscriptions resolved — agent will sit idle
```

## Root cause

Three pieces interact:

1. **Seeding:** `scripts/seed-local-community.sh` inserts each loopback host variant (`localhost`, `127.0.0.1`, `localhost:3000`, `127.0.0.1:3000`) as its **own** `communities` row. The comment says these are "loopback aliases", but with row-zero host binding each row is a fully isolated tenant:

```
SELECT id, host FROM communities;
-- 4 rows, 4 distinct community ids
```

2. **Desktop app tenant:** `scripts/instance-env.sh` defaults the app to `ws://localhost:3000`, so all channels/messages/profiles are created in the `localhost:3000` tenant.

3. **Managed-agent tenant:** the managed-agent backend keys runtime pairs by the canonical relay URL — `normalize_relay_url` (`crates/buzz-core/src/relay.rs`, mirrored in `desktop/src/features/agents/managedAgentRuntimeStatus.ts`) folds loopback hosts to `127.0.0.1` — so spawned harnesses get `BUZZ_RELAY_URL=ws://127.0.0.1:3000`. The relay resolves tenants from the literal `Host` header with no such normalization, so the agents authenticate into the **empty** `127.0.0.1:3000` tenant. `buzz-acp` discovery (kind:39002 membership scan) legitimately finds nothing.

The design assumption behind `normalize_relay_url` ("localhost and 127.0.0.1 are the same relay") and the tenant model ("one host = one community") contradict each other, and the seed script bakes the contradiction into the default dev database.

## Impact

- Out-of-the-box `just dev` + managed agents = agents never respond, with no user-visible error (members panel shows them stuck on "Waking").
- Anything keyed by tenant (channels, membership, 39002 discovery, media) silently splits between the two loopback tenants depending on which client wrote it.

## Workaround we used

Re-point the data tenant at the canonical host and align every client on `127.0.0.1:3000`:

```sql
BEGIN;
UPDATE communities SET host = '__swap__' WHERE host = '127.0.0.1:3000';
UPDATE communities SET host = '127.0.0.1:3000' WHERE host = 'localhost:3000';
UPDATE communities SET host = 'localhost:3000' WHERE host = '__swap__';
COMMIT;
```

plus `RELAY_URL=ws://127.0.0.1:3000` / `BUZZ_RELAY_URL=ws://127.0.0.1:3000` in `.env`, then re-join the community from the desktop app. After that the agent logs flip to `discovered 2 channel(s)` and mentions work.

## Suggested fixes (any one of these would prevent the trap)

1. **Normalize loopback hosts in tenant resolution** (apply `normalize_relay_url` semantics to the `Host` header before the `communities` lookup), so all loopback variants resolve to one tenant in dev; or
2. **Seed only the canonical loopback host** (`127.0.0.1:3000`) and default `instance-env.sh` / `.env` to `ws://127.0.0.1:3000`, so the app and the spawned harnesses agree; or
3. **Don't canonicalize the relay URL handed to spawned harnesses** — pass through the community URL the app itself uses; or
4. At minimum, surface a loud warning: if a managed agent's discovery returns 0 channels while the app's tenant has channels for that agent, log/notify a tenant-mismatch hint instead of idling silently.

Happy to provide more logs or test a patch.

Read scripts/seed-local-community.sh and scripts/instance-env.sh, then trace normalize_relay_url in crates/buzz-core/src/relay.rs and its mirror in desktop/src/features/agents/managedAgentRuntimeStatus.ts. Run just setup + just dev and reproduce the managed-agent flow, checking which tenant each URL selects. Done means the chosen fix keeps the desktop app and harness in one tenant and the agent discovers the channel and responds.

Written by the indexing model from the issue text.