No supported way to move an existing agent to a provider backend

# No supported way to move an existing agent to a provider backend

Looks like this is already being addressed by #2317 — leaving this open as the user-facing description of the gap unless you'd rather I close it.

`backend` is accepted by `CreateManagedAgentRequest` but not by
`UpdateManagedAgentRequest`, and creation always mints a fresh keypair. An
agent that already exists therefore cannot be moved onto a remote substrate
without abandoning its identity, history and relay reputation — you can only
create a new one.

That reads as unfinished rather than deliberate, because everything else on
that path is present:

- the record carries `backend`, and the spawn path honours it
- `buzz-backend-kubernetes` ships, and `docs/remote-agents.md` specifies the
provider protocol
- `discover_backend_providers` and `probe_backend_provider` exist as commands

Most tellingly, the local spawn path already guards on a backend that changed
underneath it:

```rust
if record.backend != BackendKind::Local {
return Err(format!("agent {pubkey} is no longer a local agent"));
}
```

"no longer", re-checked under the store lock, in three call sites
(`commands/agents.rs`, `global_agent_config.rs`, `agent_discovery.rs`). That
guard only earns its keep if a record's backend can change after creation —
which today nothing can do.

There is also no UI: no `.tsx` in `desktop/src` calls
`discover_backend_providers`, so a backend cannot be chosen when creating an
agent either. Editing `managed-agents.json` by hand does not work — the
desktop rewrites it at startup and resets `backend` to `local`.

## Use case

Running an agent on a dedicated host rather than the machine the desktop runs
on, while keeping the agent's existing identity and channel history. The
desktop otherwise always spawns a local copy of any agent it manages, so the
agent ends up running in two places.

## Questions

1. Is backend-on-update wanted, or was create-only deliberate for a reason the
code doesn't state?
2. Is the backend picker UI already planned? If it's imminent, that changes
whether this is worth doing separately.

I have a small patch that adds `backend` to `UpdateManagedAgentRequest` and
applies it in `update_managed_agent`, with the same absent-means-don't-touch
contract as the other optional fields, plus deserialization tests. It
deliberately does not restart the agent, matching that command's documented
behaviour ("Does NOT auto-restart the agent … take effect on the next agent
spawn"). Happy to open it as a PR if the direction is welcome.

Start with CreateManagedAgentRequest, UpdateManagedAgentRequest, and update_managed_agent, then inspect the deserialization tests mentioned in the issue. Compare the optional-field behavior with existing update fields and confirm the documented no-auto-restart behavior; the backend should apply on the next agent spawn.

Written by the indexing model from the issue text.