[Bug] Desktop 0.4.23 spawns managed agents on ws://127.0.0.1:3000 while the community uses ws://localhost:3000 - agents silently stop responding

## Summary

On desktop v0.4.23 (installed DMG, macOS), managed agents are spawned with `BUZZ_RELAY_URL=ws://127.0.0.1:3000` even though the active community is configured as `ws://localhost:3000`. Because the relay derives the community boundary from the Host, `localhost:3000` and `127.0.0.1:3000` are two fully isolated communities. The result: the UI posts messages into the `localhost:3000` community while every agent sits in an empty `127.0.0.1:3000` community, so agents never see any message and never reply. There is no error anywhere - the only hint is a low-key log line in the agent log.

## Environment

- Desktop app: v0.4.23, installed from DMG (GUI launch), macOS (Darwin 25.5)
- Relay: local dev relay at port 3000 (`just relay`)
- Community config in the app (localStorage `buzz-communities`): `relayUrl: "ws://localhost:3000"`
- No `BUZZ_RELAY_URL` in the app process environment, no launchctl env

## Steps to reproduce

1. Run a local relay on port 3000.
2. In the desktop app, use a community configured as `ws://localhost:3000`, create channels, add managed agents to a channel.
3. Install/launch desktop v0.4.23 from DMG and let it restore the managed agents.
4. Mention an agent in the channel.

## What happens

- The user's messages land in the `localhost:3000` community (verified in the relay DB: `events.community_id` maps to the `localhost:3000` row in `communities`).
- Every spawned `buzz-acp` child has `BUZZ_RELAY_URL=ws://127.0.0.1:3000` (verified via `ps eww`). Their membership discovery (kind 39002 query) runs against the `127.0.0.1:3000` community, which is empty, so each agent logs:

```
INFO buzz_acp: discovered 0 channel(s)
WARN buzz_acp: no channel subscriptions resolved - agent will sit idle
```

- Agents show as online (presence is set) but never respond to anything.

## Notes on the source of the rewrite

- The agent records in `managed-agents.json` have an empty `relay_url`, so the spawn falls back to the workspace relay (`effective_agent_relay_url` in `desktop/src-tauri/src/relay.rs`).
- On current `main`, the fallback chain (workspace override from `apply_workspace` -> env -> build-time -> `DEFAULT_RELAY_WS_URL`) is all `ws://localhost:3000`, and the frontend passes the stored community `relayUrl` unchanged. I could not find the `localhost -> 127.0.0.1` rewrite on `main`, so it seems specific to the 0.4.23 build (repeated agent restarts always produce `127.0.0.1`, so it is not a launch-order race).
- An earlier build on the same machine spawned agents with `ws://localhost:3000` (visible in older agent logs), so this looks like a regression introduced in or shortly before 0.4.23.

## Why this is nasty to debug

1. Nothing fails loudly. The agent connects, authenticates, sets presence to online, and then silently subscribes to nothing.
2. `localhost` vs `127.0.0.1` is invisible in the UI. The user sees online agents in the member list that simply never answer.
3. Setting `BUZZ_RELAY_URL` as a per-agent env var is rejected (it is on `RESERVED_ENV_KEYS`, which is reasonable), so the only workarounds are the per-agent Relay URL field in the Advanced section, or changing the community relay URL - the latter silently forks the community and hides all previous history.

## Suggested fixes

1. Find and remove the `localhost -> 127.0.0.1` rewrite in the agent spawn path so the child relay URL always matches the workspace relay the UI uses.
2. Consider normalizing loopback hosts (`localhost`, `127.0.0.1`, `[::1]`) to one canonical community key on the relay side, since they are the same machine and the split is never what a local user wants.
3. Make the idle state visible: when an agent discovers 0 channels, surface a warning in the desktop UI (the log line is easy to miss), since an online-but-deaf agent looks identical to a working one.