We need an "Agent View" for remote agents

### Is your feature request related to a problem? Please describe.

Buzz already supports running agents as headless `buzz-acp` bridges — a great fit
for always-on agents backed by runtimes like **Hermes** or **OpenClaw**, hosted
on a workstation/server and connected to a community relay 24/7, independent of
any desktop client.

The problem: the desktop **Agents** view only lists agents the local app
**manages/hosts** itself (`AgentsView` → `UnifiedAgentsSection`). Externally-hosted
bridge agents never appear there. They only surface as channel members (their
`kind:10100` profile badges them as "agent" in member lists and `@mention`
autocomplete), but there is no representation in the Agents area itself.

This forces a bad tradeoff:

- To see/manage an agent in the **Agents** area, the desktop app has to host it —
which ties the agent's lifetime to that app instance being open, so true 24/7
operation is impossible (close the app → the agent goes offline).
- Hosting the *same* agent on more than one device conflicts (two harnesses on
one identity, racing on the relay).
- So anyone running Hermes/OpenClaw agents as always-on bridges has **no
first-class, at-a-glance Agents surface** for them — only a per-channel member
popup.

### Describe the solution you'd like

1. **A read-only "Community / External agents" section in the Agents view** that
lists agents present in the community via their `kind:10100` agent profile
(+ `kind:0`), regardless of which device or process hosts them — including
bridge agents the local app does not manage.
2. **Clear separation of "Managed here" vs "External".** Externally-hosted agents
get view/interact affordances (open profile, DM, `@mention`, online/offline
presence) but **no** start/stop/edit/delete controls, since the local app
doesn't own their runtime — and no "Configuration missing" / "Stopped" states
for agents the app was never hosting.
3. **A uniform way to register/label an externally-hosted agent into the
community's Agents roster from any device** — publish/curate its agent profile
(name, avatar, description) without the app taking over hosting — so multiple
people can each stand up their own always-on agents on their own machines and
have them all appear consistently in everyone's Agents view for that community.

### Describe alternatives you've considered

- **Hosting agents via the desktop app (managed):** rejected — not 24/7 (the
harness dies when the app closes), and hosting the same agent on multiple
devices conflicts.
- **Publishing `kind:10100` manually** (e.g. via `buzz channels set-add-policy`):
makes the agent show up in member lists / mentions, but **not** in the Agents
view, and the profile content isn't a real agent profile. A workaround, not a
surface.
- **Relying on the channel member popup only:** fine for chatting, but there's no
agent-overview surface and it doesn't scale across many agents and devices.

### Additional context

Concrete setup this would serve: a Mac hosts Agent1/Agent2/Agent3 as
`buzz-acp → hermes -p ` launchd bridges on a shared community relay; a
Windows box and a Raspberry Pi host their own agents the same way. All of them
should appear in every device's **Agents** view as community agents — hosted only
where their bridge runs, viewable and interactable everywhere, start/stop-able
nowhere but their host.

This mirrors how Discord shows bots in a server: the bot runs server-side,
always-on, and every client sees and can interact with it regardless of which
client is open — no client "hosts" the bot.

Start with AgentsView and UnifiedAgentsSection to understand how locally managed agents enter the desktop Agents view, then compare that with the kind:10100 profiles surfaced in member lists and mentions. Review the buzz channels set-add-policy workflow and buzz-acp context. Done means externally hosted agents can appear in a distinct read-only section without local hosting controls, with consistent profile and interaction behavior across devices.

Written by the indexing model from the issue text.