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

[andydoucet]

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 — [Bug] Desktop: agent settings edits always target one community's instance - per-community agent config (env vars) unreachable from the UI #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:

// 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 [Bug] Desktop: agent settings edits always target one community's instance - per-community agent config (env vars) unreachable from the UI #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.