feat(desktop): list workspace agents on the Agents screen

[ajdavis21]

Summary

The Agents screen renders only the viewer's own managed agents and persona library (AgentsView → UnifiedAgentsSection with agents.managedAgents and personas.libraryPersonas). Agents that other workspace members run never appear there, even though the desktop already discovers them through list_relay_agents for @mention autocomplete, the DM picker, the tray menu and the sidebar working badges.

For a team that runs shared agents on a server (in our case a buzz-acp + omp agent deployed through a remote provider, owned by one member), that means everyone else has to find the agent through a channel member list or the mention picker. This adds a read-only Workspace agents section to the Agents screen so every member sees the workspace's agents in one place.

What it shows, per agent:

• name (falls back to the truncated pubkey when the directory record has none)
• avatar with the presence dot, using relay presence first and the directory's status only while presence is unknown, per docs/agent-availability.md
• second line: Managed by <owner display name> · <runtime> · in N channels, where the owner label resolves from the NIP-OA-verified ownerPubkey via one useUsersBatchQuery
• click opens the agent's profile panel (which already renders "Managed by", runtime and status for relay agents)

What it deliberately does not do: no Start / Stop / Delete. The viewer does not own these agents, and useAgentLifecycleActions already refuses to act without a local ManagedAgent. Agents the viewer manages are excluded by pubkey so nothing is listed twice.

Implementation notes:

• workspaceAgents.ts holds the pure selection, labelling and availability rules; WorkspaceAgentsSection.tsx is the view; AgentsView.tsx mounts it between the unified agents section and Agent teams. UnifiedAgentsSection and useManagedAgentActions are untouched.
• Rendered as a sibling section rather than a group inside UnifiedAgentsSection because that component is mounted by an existing test without CommunitiesProvider, which useUsersBatchQuery needs.
• One extra presence lookup over the workspace pubkeys (useAgentAvailabilityLookup), sharing the existing cache and live subscription.

Related issue

None found. Closest neighbours are the agent-directory and mention-authorization work in #6224 (relay agent discovery) and the agent availability docs; this is additive UI over the same list_relay_agents data.

Testing

• desktop/src/features/agents/ui/workspaceAgents.test.mjs: 7 node tests covering managed-pubkey exclusion (case and whitespace insensitive), duplicate collapse, blank-name fallback, sort order and undefined inputs, subtitle composition (singular/plural, blank runtime), owner-label precedence, and presence-over-snapshot availability. All pass locally.
• check-pubkey-truncation, check-px-text, check-file-sizes pass; both .tsx files transpile with no diagnostics; workspaceAgents.ts type-checks against the real RelayAgent type.
• Full tsc, biome and the Playwright e2e suite were not run locally (no node_modules on the authoring machine); relying on CI for those.
• UI screenshot: not yet attached. The authoring environment cannot build the desktop bundle; I can add a before/after capture from a CI or dev build on request. One e2e risk worth a reviewer's eye: fixtures that add foreign relay agents whose names match a managed persona could now hit strict-mode locator collisions on the Agents page.

[github-actions]

🔐 Codex Security Review

Status: review required for the current range.

The current range is e17cdd9d5c7e2b836b4670ae88bb87a79f94337a...7f7b39bb69c8ba08ae5b1b4c02b45a5cf66c70c7.
A new review must complete for this exact range. When manual authorization
is required, a Block organization member must comment exactly
@buzz-security-review 7f7b39bb69c8ba08ae5b1b4c02b45a5cf66c70c7 to authorize a new review.
Any previous review applies only to its recorded range.