[Bug] Desktop: agent settings edits always target one community's instance - per-community agent config (env vars) unreachable from the UI

**Describe the bug**

The data model stores managed agents as one definition record per persona plus one instance record **per community/relay** (`managed-agents.json`: instances carry `relay_url` and their own `env_vars`), so per-community agent configuration is clearly supported by the backend. However, the Settings → Agents UI gives no way to target a specific community's instance:

- Each built-in agent (Fizz/Honey/Bumble) appears **once** in the agent list, even when it has instances in multiple communities.
- The edit dialog does not show which community/relay the instance being edited belongs to.
- Every edit we made (adding an env var to "Fizz") was written to the **same instance** (`wss://instance1.soldo.dev`) regardless of intent — repeated attempts to configure the `wss://instance2.soldo.dev` instance always landed on the other community's instance. There appears to be no path in the UI that edits the second instance at all.

From the user's perspective, agent settings behave as if they were global across communities, and it is impossible to configure the same persona differently per community.

Concrete motivating use case: `CLAUDE_CONFIG_DIR` per community, so agents in a work community bill against a work Claude subscription while agents in a personal community bill against a personal one. The instance-level `env_vars` field is exactly right for this — it's only the UI that can't reach it.

**To Reproduce:**

1. Join two communities (self-hosted relays A and B) with the built-in agents active in both — `managed-agents.json` now contains two instance records per persona, one per `relay_url`.
2. Open Settings → Agents, edit agent "Fizz", add an environment variable under Advanced, save.
3. Inspect `~/.local/share/xyz.block.buzz.app/agents/managed-agents.json`.

Observed: the env var is written to the instance for relay A (`wss://instance1.soldo.dev` in our case) — no matter which community is active in the app. There is no UI affordance to edit the relay-B instance instead, and no indication in the dialog of which instance was edited.

**Expected behavior:**

Either of:
- The agent list/edit dialog shows one entry per community instance (or a community picker inside the dialog), labeled with the community name/relay URL, so each instance's settings (env vars, model, respond-to, …) can be edited independently; or
- at minimum, the edit dialog displays which community's instance is being edited.

**Supporting Material**

State after edits — env var repeatedly landed on the `instance1.soldo.dev` instance while trying to configure the `instance2.soldo.dev` one:

```
$ python3 - <<'EOF'
import json
d = json.load(open('.local/share/xyz.block.buzz.app/agents/managed-agents.json'))
for a in d:
print(a.get('name'), '| relay:', a.get('relay_url') or '(definition)', '| env_vars:', a.get('env_vars'))
EOF
Bumble | relay: (definition) | env_vars: None
Fizz | relay: (definition) | env_vars: None
Honey | relay: (definition) | env_vars: None
Bumble | relay: wss://instance1.soldo.dev | env_vars: None
Bumble | relay: wss://instance2.soldo.dev | env_vars: None
Fizz | relay: wss://instance1.soldo.dev | env_vars: {'CLAUDE_CONFIG_DIR': '/home/user/.claude-work'} <-- edits always land here
Fizz | relay: wss://instance2.soldo.dev | env_vars: None <-- intended target
Honey | relay: wss://instance1.soldo.dev | env_vars: None
Honey | relay: wss://instance2.soldo.dev | env_vars: None
```

**Environment (please complete the following information):**
- OS: Linux (Ubuntu 24.04 host, AppImage)
- Version: Desktop v0.4.24 (`Buzz_0.4.24_amd64.AppImage`)
- Communities: two self-hosted relays (`ghcr.io/block/buzz:main`), agents runtime: Claude Code

**Additional context**

Agent defaults (the global dialog) working app-wide is understood and fine — this report is specifically about per-instance settings being unreachable/mistargeted in the UI while the storage layer (`persona_id` + `relay_url` + per-instance `env_vars`) already models them correctly.

Start in the Settings → Agents UI and trace how the edit dialog selects an agent instance. Compare that selection with the relay_url and env_vars entries in managed-agents.json. Done means each community instance can be identified and edited independently, with changes written to the intended relay-specific record.

Written by the indexing model from the issue text.