Mentioning a provider-backed agent the desktop can't start drops the message instead of publishing it

Split out of #4839 at @TheSeydiCharyyev's suggestion — that PR fixes mention *visibility* and deliberately doesn't touch the start path. This is the start path.

## Setup

Self-hosted relay, six communities. 25 agents run as containers on my own VM, each its own `buzz-acp` with its own key. The desktop never spawns any of them and holds none of their keys. Desktop 0.5.5 on Windows 11.

## What I did

I wanted the agents to show up in the Agents tab, so I hand-wrote entries into `%APPDATA%\xyz.block.buzz.app\agents\managed-agents.json` — one per agent, `start_on_app_launch: false`, `auto_restart_on_config_change: false`, `backend: {"type":"provider","id":"...","config":{}}`, no `env_vars`.

They showed up. And mentions broke.

## What happens

Mention one of them in a channel it's already a member of, hit send:

```
Could not start agent mention: Backend · Claude: agent b0d474ab…7188 has no
private key available — the OS keyring may be unreachable. Refusing to start
without an identity; retry once the keyring is reachable.
```

The message is never published. Not delayed, not queued — `useMentionSendFlow` returns before the send, so it's gone. The agent is sitting right there in the channel and would have answered.

The keyring is fine, by the way. There's just no key in it for that agent, and there never will be — the key lives on the server.

Two paths reach it. `ensureManagedAgentMentionsReady` calls `startAgentMutation` for a participant it considers not-running, and `attachManagedAgentToChannel` does the same via `ensureRunning` for a non-participant. A provider-backed agent whose `status` isn't `deployed` takes the start branch in both.

## Why the status is never `deployed`

Because nothing sets it. There's no provider binary for my setup and there isn't going to be one — `docs/remote-agents.md` puts the provider on the desktop's machine, and the point of running the agents on the server is that the desktop stays a client with no deploy credentials on it. So the record claims a provider that doesn't exist, the app believes it, and tries to launch it.

That's my fault for writing a record that isn't true. But there's no honest thing to write instead: there's no way to register an agent as display-only. #4833 hit the same wall from the other side.

## Expected

A mention should publish. Starting an agent locally is an optimization — if it can't happen, the mention is still a valid mention, and the relay will route it to whoever is listening.

Concretely, either of these would fix it for me:

- Treat a start failure as non-fatal for the send: log it, publish the mention anyway.
- Or give the record a way to say "don't manage me" — a flag, or honouring `start_on_app_launch: false` as "never auto-start", which is what I meant when I set it.

I've been running the first as a local patch (skip the start branch for a known backend id) across six communities for a week. Mentions publish, the agents answer, nothing else changed.

## Not asking for

A provider for Docker. The relay directory already carries everything the client needs.

Start at useMentionSendFlow and trace ensureManagedAgentMentionsReady, startAgentMutation, attachManagedAgentToChannel, and ensureRunning for provider-backed agents that are not deployed. Read docs/remote-agents.md for the provider model and verify the behavior with a mention send using an agent without a local key. Done means the mention is published even when local startup cannot occur, or the record can explicitly opt out of management.

Written by the indexing model from the issue text.