fix(desktop): scope agent cards and starts to community

[unclejobs-ai]

Summary

• Prefer the managed-agent instance whose relayUrl matches the active community before considering runtime status.
• Pass the active relay and signer identity to managed-agent start and restart calls so the existing backend scope guard fails closed if the community changes mid-action.
• Keep the existing archive filtering and active-instance fallback behavior when no community match exists.

A persona can have one identity-backed instance per community. The shared card selector previously preferred a running sibling even when it belonged to another relay. Clicking Start from community B could therefore target community A's pubkey, while the backend spawned it against the active workspace relay. The result was a wrong identity on the current relay or an agent with no resolvable channel subscriptions.

This change does not alter persisted records or relay routing. It selects the instance already belonging to the active relay and binds start side effects to the relay/signer scope captured by the UI.

Related issue

• Addresses [Bug] Desktop: agent settings edits always target one community's instance - per-community agent config (env vars) unreachable from the UI #2717
• Addresses Managed-agent UI updates visible persona record but runtime launches stale identity-backed duplicate #4620
• Related but distinct: fix(desktop): stop the agents library hiding renamed agent instances #6013 changes grouping for renamed instances; this change scopes the selected instance by community relay.

Testing

• Desktop unit suite: 5,357 passed / 0 failed
• Focused selector/card suite: 11 passed / 0 failed
• TypeScript: tsc --noEmit
• Biome: changed files clean
• git diff --check

Manual macOS verification with two communities and duplicate persona instances:

1. Switch to the self-hosted community.
2. Start the persona from its shared card.
3. Confirm the spawned process uses the instance pubkey associated with that relay.
4. Send a DM and receive exact replies from both a Pi-backed and Codex-backed managed agent.
5. Stop all managed agents and confirm no start-on-launch records were enabled.

No visual layout changes.

[Chessing234]

ranking the active community's identity above runtime status is the right call — a running sibling from another community is exactly the wrong thing to show on a profile.

the tiebreak is raw string equality on the relay URL though:

Number(right.relayUrl === preferredRelayUrl) - Number(left.relayUrl === preferredRelayUrl)

that only holds if both sides are already canonical. wss://current.example vs wss://current.example/, or a case difference in the host, compares false and the comparator silently falls through to status ordering — which is the pre-fix behaviour, so the bug comes back with no signal that the preference was ignored. this codebase has had that shape before with hex ids and repo owners.

is relayUrl guaranteed canonical from both sources here — the persisted agent record and whatever useCommunities hands you? if they come from different writers at different times, normalising both before comparing (or comparing parsed origins) would make the tiebreak actually hold.

the undefined case is fine, for what it's worth: with no preferredRelayUrl both terms are false and it falls through cleanly.