Feature Request: Support external agent systems (non-ACP) for real-time communication in Buzz communities

## Problem

Buzz's agent model currently requires agents to run as ACP subprocesses spawned by `buzz-acp` (Claude Code, Goose, Codex, etc.). External agent systems — like OpenClaw, custom backends, or any non-ACP agent platform — cannot participate in real-time Buzz conversations.

Today, the only ways for an external agent to interact with a Buzz community are:
1. **`buzz-cli`** — a one-shot REST CLI tool. No persistent connection, no real-time message receiving.
2. **`buzz-acp` with a supported harness** — spawns its own agent subprocess, which means the agent identity is tied to the harness (e.g., Claude Code), not to an external agent system.

This means if you run an AI assistant on your own infrastructure (OpenClaw, a custom backend, etc.) and want it to participate in a Buzz community alongside humans, there is no real-time path.

## Use Case

We run an AI assistant (DeanAI) on OpenClaw with Discord, Telegram, and Google Chat integrations. We set up a Buzz community for human-agent collaboration between:
- **Dean** (human, Buzz desktop app)
- **DeanAI** (AI on OpenClaw, currently can only use `buzz-cli` for one-shot REST calls)
- **DeanWynn** (another AI instance on a separate machine)

DeanAI can post messages via `buzz-cli`, but cannot **receive** messages in real-time. When Dean sends a message in Buzz, there's no listener to pick it up and route it to OpenClaw. The conversation is one-directional without manual polling.

## Proposed Solutions (any one would solve this)

### Option A: Webhook-based agent integration
Allow registering a webhook URL per agent identity. When the agent is @mentioned or a message arrives in a subscribed channel, Buzz POSTs the event to the webhook. The external agent processes it and responds via `buzz-cli` or a REST API call.

### Option B: WebSocket listener mode in `buzz-cli`
Add a `buzz listen` command that maintains a persistent WebSocket connection to the relay, streaming incoming events as JSON to stdout. External systems can pipe this into their own processing pipeline and respond via `buzz-cli` commands.

### Option C: Custom agent command in `buzz-acp`
Allow `--agent-command` to point to an arbitrary executable (not just Claude Code/Goose/Codex) that speaks a simple JSON-in/JSON-out protocol over stdio — essentially a generic bridge mode. This would let external systems write a thin shim script that forwards messages to their own API.

## Environment
- Buzz relay: local (port 18800) and hosted community (`daveryai.communities.buzz.xyz`)
- `buzz-cli` v0.1.0 installed and working
- `buzz-acp` compiled but not running (no compatible agent harness configured)
- External agent: OpenClaw on Linux (WSL2)

## Current Workaround
Manual polling via `buzz messages get --channel --limit N` on a cron — but this is not real-time and adds unnecessary latency.

---

Happy to contribute or help test any of these approaches. Thanks for considering!