Managed agent nest and memory store are shared across all communities: private workspace files and agent memory pool between tenants

## Summary

Buzz Desktop gives every managed agent on a machine the **same nest** — one working directory (`~/.buzz` / `C:\Users\\.buzz`) and therefore one Claude Code project-memory store — regardless of which community the agent belongs to. Community membership scopes messages on the relay; it scopes nothing on disk.

The practical result is that an agent belonging to community A boots every session with community B's private working documents in its working directory and community B's accumulated memories auto-injected into its context, without having participated in any of that work.

#3106 reports a subset of this (the roster/relay info in `AGENTS.md`) and frames it as a display concern. This issue is about the rest of the nest — `RESEARCH/`, `OUTBOX/`, `PLANS/`, `WORK_LOGS/`, and the agent memory store — where the content is substantive rather than cosmetic.

## Environment

- Buzz Desktop, Windows 11
- Three communities signed in on one account, each with its own relay subdomain
- Managed Claude agents (`buzz-acp` + `claude-agent-acp` 0.63.0)

## Evidence

There is exactly one nest directory under the user profile and exactly one corresponding Claude project directory (`.claude/projects//`), so there is exactly one memory store. All agents across all three communities run in it.

Inspecting the nest from a community-A agent's session:

- `RESEARCH/` — 8 of 9 files are community-B project documents
- `OUTBOX/` — ~30 files, nearly all community-B material, including in-progress review documents that had not yet been published anywhere
- `memory/` — 5 of 10 memories are community-B findings, indexed in the `MEMORY.md` that is auto-injected into **every** session

Attribution is unambiguous. The community-A agent's own session log (91 KB) contains **zero** occurrences of the string identifying that project; the community-B agent's log contains 11. The community-A agent did not produce any of it — a different community's agent wrote it into the shared nest, and every other community's agents read it from there by default.

The flow is bidirectional: anything a community-A agent writes is equally readable by community-B and community-C agents.

## Why this matters

For anyone using one Buzz install across a personal community and one or more client/business communities — the exact scenario in #3106 and #2515 — the nest is a standing cross-tenant channel. Relay membership separates what agents can *say*; it does not separate what they *know*. Un-published drafts and working notes are precisely the material most likely to be sensitive, and they pool in the one location every agent reads on startup.

This is a standing condition rather than an incident: it does not require a misconfiguration or a mis-click to trigger, and there is currently no setting that scopes it.

## Expected

The agent nest — and the memory store derived from it — should be scoped per community, e.g. `~/.buzz//`, so that `RESEARCH/`, `OUTBOX/`, `PLANS/`, `WORK_LOGS/` and memory cannot pool across communities. Failing that, Desktop should make the sharing explicit and opt-in rather than silent and default.

## Actual

One nest and one memory store, shared by every agent on the machine across every community, with no indication to the user and no way to scope it.

## Related

- #3106 — same shared directory, scoped to the roster file; states channel membership is correctly scoped, which does not hold once an agent has been launched cross-community (see #2515)
- #2515 — foreign agent identity active in another community's channel; root cause posted there
- #3371 — managed agents inherit the *owner's personal* Claude Code config and auto-memory. Adjacent but distinct: that is host-config bleed into agents, this is agent-to-agent bleed **between communities**. Note that #3371's second root cause (the nest living inside `$HOME`, so ancestor project-memory resolves into it) is the same structural weakness seen from another angle.
- #3822 — RFC for explicit per-channel `cwd`. Motivated by per-repository scoping rather than tenant isolation, but a `cwd` that is a first-class, resolved input is the mechanism this fix would need.