No per-community data isolation on Desktop: managed agents, conversation memory, and local state are shared across every connected community

## Problem

Buzz Desktop supports connecting to multiple communities (each backed by a different relay) from one install, but local state is not partitioned by community. Confirmed several distinct pieces of this tonight while auditing a real multi-community setup:

1. **Managed agent records are global, not per-community.** `managed-agents.json` lives at a single Tauri `app_data_dir()` path (`desktop/src-tauri/src/managed_agents/storage.rs:35-46`, `managed_agents_base_dir`) — one file for the whole install, not one per community. `useManagedAgentsQuery`/`listManagedAgents()` (`desktop/src/features/agents/hooks.ts:354-374`) takes no relay/community parameter. See #6369 for the narrower UI-display consequence of this.
2. **Agent conversation memory/workdir is shared at the OS level.** Every agent process on a given Desktop install runs under the same OS user account with access to the same local filesystem — there's no OS-level (separate account/container) boundary between what an agent can read while acting for Community A versus Community B.
3. **This was already a stated requirement, not a new ask.** `RESEARCH/SELF_HOSTED_BUZZ.md` (2026-08-15, in the requesting team's own planning docs) called for no agent bleed-over between two specific communities on one install. It was never implemented for the agents already running at the time.

## Why this matters

For any multi-tenant use case — an agency running one community per client, an MSP, a platform hosting isolated customer workspaces — this is a real data-isolation gap, not a cosmetic one. An agent identity (or its underlying process/memory) that's reachable from multiple communities can carry context between them. Community switching does reset the community-scoped UI state (`resetCommunityState()`, `desktop/src/features/communities/useCommunityInit.ts`) — channels, messages, membership — but that reset does not extend to managed-agent records or to the shared local filesystem/process space agents run in.

## Suggested direction (not fully speced — needs product/security design input)

Partition local agent state by community: e.g. a per-community subdirectory under the app data root (analogous to per-community `~/.buzz`), with managed-agent records, conversation memory, and any read/write access rules scoped to that directory rather than the single global store. This is a bigger architectural change than a UI filter — likely needs:
- A decision on whether isolation happens via separate directories within one process, separate OS-level accounts/processes, or containers per community.
- A migration path for existing installs that already have agents spanning multiple communities.

Filing this to get it tracked and get maintainer/architecture input, not proposing a specific implementation yet — didn't want to guess at a security-sensitive design decision without that input.

## Related

- #6369 — narrower symptom of point 1 above (Agents page UI has no per-community filter). This issue is the broader architectural gap; #6369 is one visible consequence of it.