No community-scoped env tier: any record can spawn into any community carrying another community's credentials

**Is your feature request related to a problem? Please describe.**

Under agents-everywhere (#2122), `effective_agent_relay_url()` deliberately ignores a record's `relay_url` pin: any managed-agent record can be spawned into any community, and the pair is identified by the workspace relay. That design leaves **no supported place to put community-scoped configuration** — most importantly credentials:

- **Per-record `env_vars` follow the agent into every community it spawns on.** A record configured with community A's memory/API key can be started into community B's relay (the Agents UI targets persona instances non-deterministically — #2717 — and launch-restore spawns every `start_on_app_launch` record into every workspace relay), and it takes community A's credentials with it.
- **Global `env_vars` are one value for all communities**, so they can't distinguish either.

We hit this concretely running two communities from one desktop, each with its own memory-service account (same shape as #2717's motivating `CLAUDE_CONFIG_DIR`-per-community case): a restart cycle spawned records into the other community's relay carrying the other community's API key — a silent cross-tenant credential leak, with data written into the wrong account's store. On 0.5.3 the only reliable workaround we found was wrapping the harness binaries in a shim that re-derives the key from `BUZZ_RELAY_URL` at exec time — which works precisely because the *effective relay in the spawned process env* is the only community signal that is always truthful.

**Describe the solution you'd like**

A relay-keyed env tier in the global agent config — location-scoped where the existing tiers are identity-scoped, matching the agents-everywhere model instead of fighting it:

```jsonc
// global-agent-config.json
{
"env_vars": { "SHARED_KEY": "..." },
"community_env_vars": {
"wss://work.example.com": { "MEMORY_API_KEY": "work-key", "CLAUDE_CONFIG_DIR": "/home/u/.claude-work" },
"wss://personal.example.com": { "MEMORY_API_KEY": "personal-key", "CLAUDE_CONFIG_DIR": "/home/u/.claude-personal" }
}
}
```

Injected at the single descriptor resolver keyed by the **effective** spawn relay, layered `global < community < persona < per-agent`, with the same reserved/derived/malformed-key rules as every other tier. Because it keys off the effective relay rather than the record, it stays correct no matter which record the UI or restore path picks for a community.

I have a working implementation (spawn, spawn-config hash so community edits trigger the auto-restart flow, per-pair status/readiness, validation, tests) and will open a PR referencing this issue.

**Describe alternatives you've considered**

- Per-instance `env_vars` via the UI — defeated by #2717 (edits/starts target one community's instance) and by design under agents-everywhere: the env follows the record, not the community.
- One `CLAUDE_CONFIG_DIR`-style value in global env — one value for all communities, same problem.
- Harness-binary shims routing on `BUZZ_RELAY_URL` (our current workaround) — works, but is exactly the kind of out-of-band machinery this feature would make unnecessary.

**Additional context**

Observed on Buzz Desktop 0.5.3 (macOS), two communities on one install. Happy to share forensic detail (process env captures, spawn logs) if useful.

Start at the single descriptor resolver keyed by the effective spawn relay, then review the existing global, community, persona, and per-agent environment tiers and their validation rules. Check the spawn path, spawn-config hash, auto-restart flow, per-pair status/readiness, and related tests; done means community-scoped values stay with the effective relay and are validated consistently.

Written by the indexing model from the issue text.