Agents tab is not community-scoped: card, profile name and public key belong to three different entities — and per-agent settings land on the wrong instance

**Environment:** Buzz Desktop on macOS (a Windows machine is paired under the same owner identity). Two self-hosted communities: `leevia.communities.buzz.xyz` and `knowhow.communities.buzz.xyz`. Builtin agents Fizz / Honey / Bumble, custom agents Nemo and Oracle.

Relay-side state is correct throughout (`buzz channels members` and `buzz users presence` agree with expectations). Everything below is local to the desktop client.

## Identity model observed

On this Mac each **builtin** agent has one identity **per community**, created at different times:

| Persona | Mac · leevia | Mac · knowhow |
|---|---|---|
| Fizz | `bf667ab3…` (created 2026-07-30T22:23Z) | `9dd15fbb…` (created 2026-08-03T20:42Z) |
| Honey | `612eeaae…` | `56769d9e…` |
| Bumble | `f74495db…` | `0bb9f108…` |

Custom agents (Nemo, Oracle) instead reuse **one** key across both communities.

## 1. The Agents tab renders the same list in every community

Screenshots taken minutes apart, switching only the active community: the agent cards are identical (`Fizz PC`, `Honey PC`, `Bumble PC`). Only the channel list in the sidebar changes. There is no visual cue anywhere that these cards belong to a specific community.

## 2. Card name, profile name and public key are three different entities

Opening the card labelled **`Fizz PC`**:

- profile heading shows **`Fizz Mac`**
- `Public key` shows **`9dd15fbb…9dd8`** — the **knowhow** instance
- and it shows **the same `9dd15fbb…9dd8` while the active community is `leevia`**, where this persona's instance is `bf667ab3…` and its `buzz-acp` process is running.

Same defect on a custom agent: the card labelled **`Wally PC`** opens a profile titled **`Nemo Mac`** with key `758f820f…44b0`. (`Wally` is an agent created on the *Windows* machine; `Nemo Mac` is a different agent that only exists on the Mac. The two got merged into one persona record — see block/buzz#3204 for the sync side of this.)

The `PC` suffix comes from the local store: **persona** records (no `pubkey`) are named `Fizz PC` / `Honey PC` / `Bumble PC` / `Wally PC`, while **instance** records are named `Fizz Mac` / `Honey Mac` / `Bumble Mac` / `Nemo Mac`. The card renders the persona name, the profile renders the instance name.

## 3. `Instances (2)` is the only place both identities appear — and it does not distinguish them

The profile has an `Instances 2` row whose two entries are labelled **identically** and differ only by `Current` / `Stopped`. No community, no machine, no key fragment. This is the only control from which the owner can act on a specific instance, and it gives him nothing to choose by.

## 4. Consequence, reproduced today: a per-agent setting landed on the wrong instance

The owner set "start on app launch" for the three agents he actually works with (the **leevia** ones). Reading `managed-agents.json` right after:

```
Fizz · knowhow 9dd15fbb start_on_app_launch=True updated 2026-08-07T00:49:15Z
Honey · knowhow 56769d9e start_on_app_launch=True updated 2026-08-07T00:49:10Z
Bumble· knowhow 0bb9f108 start_on_app_launch=True updated 2026-08-07T00:49:02Z
Fizz · leevia bf667ab3 start_on_app_launch=False (untouched)
Honey · leevia 612eeaae start_on_app_launch=False (untouched)
Bumble· leevia f74495db start_on_app_launch=False (untouched)
```

The flag was written to the three **knowhow** instances. The owner had no way to notice: the UI showed him the cards he expected.

Net effect if unnoticed: on the next app launch the client starts the three agents that are **not** members of any working channel, and leaves the three that are — which is exactly the incident that started this: on 2026-08-06 two agents silently failed to come back and no surface reported it.

## What we need

1. **Scope the Agents tab to the active community** (or label each card with its community/machine). Requested previously on 2026-08-03; this issue is the visual evidence.
2. **Make the profile show the instance of the active context** — heading, public key and settings must refer to the same entity.
3. **Label instances** in the `Instances` list with community and machine, not just `Current` / `Stopped`.
4. **Apply per-agent settings to the instance the user is looking at**, and show which one was written.
5. Product-level: let an agent be **bound to a machine + community** so the client does not create or display cross-community instances. Desired setup here: knowhow agents live on the Windows machine, leevia agents on the Mac.

## 5. The `Auto-start` toggle lives at profile level and is bound to the wrong key

The agent's overflow menu offers: `Auto-start` (toggle), `Duplicate`, `Export`, `Archive agent`, `Delete agent`. There is no per-instance control in that menu, and the profile it belongs to is the one showing `9dd15fbb…9dd8` — the knowhow instance. That is why the flag in section 4 landed where it did: the toggle applies to whichever instance the profile decided to show, which is not the one bound to the active community.

The `Instances (2)` list shows both entries labelled identically (`Fizz Mac`), tagged `Current` and `Running` in one screenshot and `Current` and `Stopped` in another taken minutes earlier — with both `buzz-acp` processes alive in `ps` the whole time. Neither tag identifies the community or the machine.

Also worth noting for a user with two machines: the only destructive-sounding options offered are `Archive agent` and `Delete agent`, both worded at **agent** level while the entity actually being displayed is an **instance**. It is not discoverable whether archiving would remove one identity or both.

## Evidence

Four screenshots of the Agents tab (same session, switching only the active community) will be attached to this issue by the reporter. All identity/state claims above were cross-checked against the local store `~/Library/Application Support/xyz.block.buzz.app/agents/managed-agents.json`, the runtime receipts in `agents/agent-pids/`, live `ps` output, and the relay itself via `buzz channels members` / `buzz users presence`.

Related: #3204 (mention picker built from the local agent registry instead of channel members) — same underlying assumption that the local agent list is the source of truth for a community-scoped view.

Start with the Agents tab and its Instances (2) list, then compare the displayed context with managed-agents.json and agents/agent-pids/. Reproduce the issue while switching between the two communities and verify which instance receives the Auto-start change. Done means cards, profiles, labels, and settings consistently identify and target the active community and machine instance.

Written by the indexing model from the issue text.