Custom-harness agents with steering_supported=false never receive mentions (silent, no error)

**Describe the bug**

An agent on a custom ACP harness that reports `steering_supported=false` is subscribed to a channel and shown as online, but **never receives any mentions**. No error surfaces anywhere — the agent simply stays silent forever. Agents whose harness reports `steering_supported=true` receive mentions in the same channel normally.

I hit this with a custom harness wrapping `gemini-cli` (`gemini --acp`, v0.53.1). The Gemini CLI itself is fine — see "Ruled out" below.

**Evidence**

Three agents, same community, all subscribed to the same channel, all `subscribe=Mentions`:

| Agent | harness | `steering_supported` | receives mentions? |
|---|---|---|---|
| ChatGPT | `@agentclientprotocol/codex-acp` | `true` | yes |
| Claude | `@agentclientprotocol/claude-agent-acp` | `true` | yes |
| Gemini | `gemini-cli` (custom harness) | **`false`** | **no** |

The two working agents log delivery activity on every mention:

```
INFO buzz_acp::acp: steer success: renewed hard deadline (7200s from now)
INFO buzz_acp: non-cancelling steer ack received channel= event_id=...
INFO buzz_acp::queue: extending in-flight deadline by 7200s + 100s buffer channel_id=
```

The Gemini agent, in the same channel over the same period, logs **nothing at all** after startup:

```
INFO buzz_acp: buzz-acp starting: ... subscribe=Mentions ...
INFO buzz_acp: agent initialized agent=0 name="gemini-cli" steering_supported=false
INFO buzz_acp: agent_pool_ready agents=10
INFO buzz_acp: connected to relay at wss://
INFO buzz_acp: discovered 2 channel(s)
INFO buzz_acp: subscribed to channel
INFO buzz_acp: presence set to online
<-- no further lines, across many mentions over multiple hours -->
```

Every mention delivery path that appears in the working agents' logs goes through `steer`. That suggests mention delivery is gated on steering support, and harnesses that report `steering_supported=false` fall through with no fallback and no warning.

**To reproduce**

1. Register a custom harness for an ACP agent that does not support steering (e.g. `gemini --acp`, gemini-cli 0.53.1).
2. Create an agent using that harness and add it to a channel.
3. `@mention` the agent in that channel.
4. The agent shows online and healthy; its log records nothing; no reply ever arrives; no error is raised.

**Expected behavior**

Mentions should be delivered to agents regardless of steering support — steering is an optimisation for interrupting/updating an in-flight turn, not a prerequisite for starting one. Failing that, Buzz should surface a clear readiness error (like it does for missing adapters/logins) rather than showing the agent as online and healthy.

**Ruled out** — the CLI, credentials, and protocol are all verified good outside Buzz:

- `gemini -p "Reply with exactly one word: working"` with the same API key → returns `working`
- ACP handshake works: piping `{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":1,"clientCapabilities":{}}}` into `gemini --acp` returns a valid result advertising `protocolVersion: 1`, `agentInfo.name: "gemini-cli"`, and `authMethods` including `gemini-api-key`
- Buzz's own model dropdown successfully lists live Gemini models for this harness (so Buzz can authenticate to the provider)
- No auth/credit/config errors in the agent log — the log is simply empty after startup
- Persisted across: agent restart, "Save changes" redeploy, killing the orphaned worker PID, and a full app restart

**Additional context**

Also worth noting: when the agent's worker process becomes orphaned, "Save changes" and the profile restart button silently no-op — the worker keeps running with stale config and the log stays frozen. Killing the PID from `agents/agent-pids/` was the only way to force a genuine respawn. That made this bug considerably harder to diagnose, since every fix appeared to apply but changed nothing.

**Environment**

- OS: Windows 11
- Buzz version: 0.5.2 (Windows, unsigned alpha build)
- gemini-cli: 0.53.1, invoked as `gemini --acp`
- Working comparison harnesses: `@agentclientprotocol/codex-acp` 1.1.7, `@agentclientprotocol/claude-agent-acp` 0.64.0