Provider `deploy` carries no intent signal, so a remote host cannot honour an owner `!shutdown` across a workspace apply

Since `desktop-v0.5.6`, `reconcile_on_workspace_apply`
(`desktop/src-tauri/src/commands/agents/provider_access.rs`) redeploys every
provider-backed managed agent with a `backend_agent_id` in an owner-only-access
build — per its doc comment, "before each community UI load".

(The exact trigger frequency isn't the point here, and I haven't pinned it down
from outside: what matters is that a provider can now receive a deploy that no
human asked for.)

That deploy is byte-indistinguishable from the one an owner triggers with
"Start":

- both call `deploy_to_provider` with the same argument shape and no intent
parameter (`commands/agents.rs`, Start at the `StartTarget::Provider` arm and
reconcile at `provider_access.rs`);
- both bottom out in `provider_deploy` (`managed_agents/backend.rs`), which
emits `{"op":"deploy","request_id":,"agent":…,"provider_config":…}`;
- `build_deploy_payload` produces the same `agent` object for both.

**Why this is a problem for a conforming provider.** The remote-agents spec's
stop semantics (owner `!shutdown` over the relay → drain, publish presence
`offline`, stay down) require the host to remain down until the owner says
otherwise. An unconditional `deploy` is also the sanctioned way back up. With no
way to distinguish the two, a host has exactly one lever with two settings:

- honour every deploy — an owner who stops an agent gets it back the next time
they open the community UI; or
- honour none — Desktop's "Start" no longer works for a stopped agent.

We chose the first, since breaking "Start" is worse for operators, and we now log
and report the revive. But neither option is correct, and no heuristic recovers
the distinction: `request_id` is random on both paths, and "reconcile deploys all
agents at once" degenerates for anyone running a single provider-backed agent.

**Suggested fix**, either would do:

1. Add a discriminator to the deploy request — e.g. `"reason": "start" |
"reconcile"` — so a provider can apply reconcile semantics (update config in
place) without treating it as fresh owner intent to run.
2. Have `reconcile_on_workspace_apply` skip records the owner has stopped.

Happy to send a PR for (1) if that shape is agreeable.

**Context:** found while upgrading a Torana gateway's pinned Buzz CLI from
`desktop-v0.5.5` to `desktop-v0.5.6`. The CLI command surface is byte-identical
between those tags; this was the only behavioural change that reached us.

Start in desktop/src-tauri/src/commands/agents/provider_access.rs and compare reconcile_on_workspace_apply with the StartTarget::Provider arm in commands/agents.rs. Trace both paths into managed_agents/backend.rs, especially deploy_to_provider, provider_deploy, and build_deploy_payload. Done means a provider can distinguish workspace reconciliation from an owner-requested start without breaking either behavior.

Written by the indexing model from the issue text.