Agents page lists every local managed agent, not just agents active in the currently viewed community

## Problem

The sidebar **Agents** page (`desktop/src/features/agents/ui/AgentsView.tsx`) lists every managed agent that has ever been created on the local Desktop install, with no filtering by which community/relay is currently active.

Confirmed in the data path, not just the UI:
- `useManagedAgentsQuery` (`desktop/src/features/agents/hooks.ts:354-374`) calls `listManagedAgents()` with **zero parameters** — no relay/community argument anywhere in the query.
- `useManagedAgentActions` (`desktop/src/features/agents/ui/useManagedAgentActions.ts`) only filters the resulting list by running/idle status, never by community.

So switching the active community tab never changes what the Agents page shows — it always renders the full local inventory of agent records on that machine, whether or not any given agent is actually a member of (or was ever deployed to) the community currently being viewed.

## Impact

For anyone running multiple communities from one Desktop install, this is confusing and looks like a data-hygiene bug even when it isn't one: agents that were only ever added to Community A also show up while viewing Community B, with no indication they aren't actually present there. In our case this made a fully-cleaned-up community (verified via direct relay DB query — zero membership/channel rows) look like cleanup had failed, because the Agents page kept showing agents that were never actually members of that community at all.

## Suggested fix

`ManagedAgentRecord` already carries a `relay_url` field (`desktop/src-tauri/src/managed_agents/types.rs`). The Agents page could filter (or group) its list by whether `relay_url` matches the currently active community, rather than showing the unfiltered global inventory.

**Open design question that needs a decision before implementing:** it's not yet clear whether `relay_url` reliably reflects every community an agent is actually present in, or just the community it was originally created in — `bootstrapManagedAgentRuntimePairs` (`desktop/src/features/agents/managedAgentRuntimeHooks.ts`) suggests agents can get a "lazy pair" reconciled into other communities after creation, which may mean an agent can be legitimately active in a community other than the one in `relay_url`. Filtering naively on `relay_url` alone could hide an agent from a community it's actually deployed to. Would like maintainer input on the intended semantics here before a PR lands, rather than guessing.

## Environment

Found and verified 2026-08-20 while auditing Buzz Desktop v0.5.16 against a self-hosted relay (multi-community setup: two separate communities on one Desktop install).