fix(desktop): use relay presence for remote agent Deploy control

[olympusbuildz]

Problem

Remote (provider-backed) agents whose process has exited still show online in the profile panel and keep a primary remote-halt control, so there is no UI path to Deploy again. Channel members sidebar already shows the correct offline presence.

Root cause

Two axes exist and are documented:

• status / isManagedAgentActive = infrastructure still recorded (backend_agent_id present becomes deployed)
• relay presence = harness actually connected

Profile avatar, primary action label, and lifecycle start-vs-halt all read the infrastructure axis for managed bots. For provider agents that axis never clears when the pod exits.

Fix

• Add presence-aware helpers in managedAgentControlActions: isManagedAgentPresenceLive, isManagedAgentLive, resolveManagedAgentDisplayPresence
• Provider primary remote-halt / Deploy affordances and profile avatar use relay presence
• Local agents still use infrastructure status
• Wire presence through profile lifecycle hook and members-sidebar agent action

Why it matters

Kubernetes/provider agents that idle-exit become unreachable from the UI until managed-agents.json is hand-edited. Deploy is already idempotent and replaces terminated pods.

Test plan

cd desktop
node --import ./test-loader.mjs --experimental-strip-types --test \
  src/features/agents/lib/managedAgentControlActions.test.mjs

10 passed @ b26c74a779634dd78800b3685fa85481e6a8415b

Named cases:

• provider deployed + offline → Deploy / not live
• provider deployed + online/away → remote-halt / live
• provider process-gone status + online → presence wins (remote-halt)
• local running/stopped labels unchanged
• missing presence on provider → Deploy

Manual verify

1. Provider-backed agent with live presence → profile + sidebar show remote-halt; avatar online
2. Same agent after process exit (presence offline) → avatar offline, primary Deploy, click starts deploy path
3. Local agent start/halt controls unchanged

Risk / blast radius

Desktop UI only. Delete-with-confirm already used presence; bulk active filters still use infrastructure status intentionally.

Closest work

none found (open PR search for #5938 / remote agent presence Deploy)

Fixes

Fixes #5938

Peer-review harden

Addressed @themiguelamador review @ d0ab6fa1a:

• resolveManagedAgentDisplayPresence uses infrastructure status for local agents; relay presence only for provider-backed
• UserProfilePanel.tsx stays at 999 lines (≤1000 ratchet) by co-locating the presenceStatus prop

[themiguelamador]

Two issues need correction before merge:

• resolveManagedAgentDisplayPresence ignores its agent argument and uses relay presence for every managed agent. A running local agent with no presence row therefore regresses from online to offline in the profile, contradicting the intended local/infrastructure behavior. The helper should use infrastructure status for local agents and relay presence only for provider-backed agents.
• The added prop line pushes UserProfilePanel.tsx beyond the repository file-size ratchet (1,000 → 1,001 by the gate’s count), so pnpm check fails on the PR as submitted.

I prepared a signed fix for both findings: https://github.com/Complear/buzz/commit/ef7eebad0

Verification on the fix:

• focused managed-agent control tests: 10 passed
• full desktop unit suite: 4,959 passed
• Biome/file-size/text/pubkey checks pass (only unrelated pre-existing warnings/info)
• TypeScript typecheck passes
• git diff whitespace check passes

[olympusbuildz]

Addressed review (new commit d0ab6fa1a):

1. Local display presence — resolveManagedAgentDisplayPresence uses infrastructure (running/deployed → online) for local agents; provider-backed still uses relay presence only.
2. File-size ratchet — UserProfilePanel.tsx remains 999 lines (prop co-located; no net growth past 1000).

Mini: managedAgentControlActions.test.mjs → 12 passed; check-file-sizes clean @ d0ab6fa1a.

Thanks @themiguelamador.

[jiwonschol]

Confirming this is worth landing — we hit exactly the scenario this PR describes on 0.5.23.

Setup: four agents run as headless buzz-acp systemd services on a VPS. Their desktop records carry backend: {"type":"provider","id":"ssh","config":{}} so the desktop treats them as remotely executed and does not reactively spawn local copies (that part works well — verified no duplicate process on the Mac with the app running).

The symptom: every @mention of one of those agents raises

Could not start 동준 — your message was sent, but the agent may not respond.
provider 'buzz-backend-ssh' not found on PATH

The message is published and the agent does answer — it has been running the whole time and picks the event up from the relay. The desktop just has no way to know that, so it attempts a deploy it does not need.

Using relay presence as the gate, as this PR does, would suppress the attempt entirely for agents that are already online. The alternative available today is to install a stub buzz-backend-<id> purely to silence the toast, which means putting a binary that receives the agent's nsec on PATH for cosmetic reasons — clearly worse than checking presence first.

Related: #2857 (duplicate remote starts) and #6484 (disable_local_spawn) cover the neighbouring half of this.