feat(gateway): per-agent Buzz identities — N agents, N workspace members, one gateway process

[jethac]

Stacked PR — do not merge before its base. This branch is
feat/single-gateway-multi-agent-rebased (#62944), rebased onto current
main, plus the five wiring commits described below. Review them on top of
#62944.

Builds on the bundled Buzz adapter merged in #73610 (@rob-coco's
#71610, salvaged by @teknium1 — including the scoped identity lock and
_resolve_user_name negative caching). Earlier revisions of this branch
carried rob's adapter commits directly; they were dropped when #73610
landed on main, and the wiring was re-fitted on top of the hardened
adapter (clean apply; the identity lock keys on relay_url:pubkey, so N
per-agent identities in one process take N distinct locks). All credit
for the adapter — including the block/buzz#2897 DM workaround — remains
@rob-coco's; this PR only builds on it.

What

Buzz (Block's Nostr-based human+agent workspace) has a property no other
supported platform has: an identity is just a keypair. No bot registration,
no app review — a new workspace member costs one nsec. That makes it the
first platform where #62944's agent registry can be taken to its logical
conclusion: every agent in the registry can be its own workspace member.

This PR wires that up. Each agent that declares a Buzz credential gets its
own relay connection inside the one gateway process:

• it appears in the workspace member list under its own key and display name;
• channel messages dispatch to the agent whose own identity is @mentioned
  (per-agent mention gate, per-agent require_mention);
• DMs dispatch to the agent whose key they address (per-recipient p-tag
  classification — the fix(tools): treat Slack channel IDs as explicit send_message targets #2897 workaround, applied per identity);
• replies always leave on the connection the message arrived on, so the
  answer is authored by the member that was addressed — fail-closed: if an
  agent's connection is down, the gateway refuses to answer as anyone else.

Config surface

gateway:
  agents:
    chip:
      home_dir: ~/.hermes/agents/chip
      buzz:
        nsec_env: CHIP_BUZZ_NSEC     # NAME of the env var holding chip's key
    scout:
      home_dir: ~/.hermes/agents/scout
      buzz:
        nsec_env: SCOUT_BUZZ_NSEC
        require_mention: false        # any adapter setting, per agent

Design decisions, and why:

• agents.<id>.buzz.nsec_env (a name, never a value). This follows the
  existing feat: single gateway, multiple agents — rebased onto current main (supersedes #25660) #62944 idiom (AgentProfile.api_key_env) and the
  gateway.multiplex_profiles secret discipline: config names credentials,
  .env holds them. Resolution order is gateway secret scope / process env
  first, then the agent's own <home_dir>/.env (the agent-registry analogue
  of a profile home). There is deliberately no fallback to the shared
  BUZZ_PRIVATE_KEY — a misconfigured agent stays offline rather than
  connecting as another member.
• Zero schema changes to the registry. load_agent_registry already
  forwards unknown agent keys into AgentProfile.config_overrides, so the
  buzz: block needs no changes to agent/profile.py.
• Connection identity is the routing decision. Per-agent adapters get
  set_routing_context(routes=[], default_agent=<agent_id>): a message that
  arrived on chip's connection was addressed to chip's member key, so the
  gateway routes: table is not consulted for these adapters (a generic
  {platform: buzz} route must not steal messages from the member they were
  sent to). The select_agent plugin hook still runs. Everything downstream
  is untouched feat: single gateway, multiple agents — rebased onto current main (supersedes #25660) #62944 machinery: source.agent_id → session-key namespace →
  AgentProfile ContextVar → per-agent home/model/toolsets.
• Same-key collisions are refused at startup (salted fingerprints, same
  scheme as the multiplex same-token guard): one key cannot be two members,
  and two pollers on one key would race per message.
• Agent-scoped settings precedence. For per-agent connections the
  agent's block wins over process-wide BUZZ_* env vars (N connections in
  one process: a global var can only be a shared default). Legacy
  single-connection precedence (env > extra) is byte-identical when
  agent_id is absent — the adapter suite from feat(gateway): Buzz (Block/Nostr) platform adapter — bundled plugin (salvage #71610) #73610 passes unchanged.

What this inherits from the adapter (#71610 via #73610)

The adapter's polling loop, mention gating/stripping, and the
block/buzz#2897 DM workaround (dms list returns [] for recipients on
some relays; DMs are recovered from channels list and latched by the
structural recipient p-tag) are rob-coco's work and are inherited as-is —
now instantiated once per agent, so each connection classifies DMs against
its own pubkey. The workaround was validated against a live relay in this
PR's integration test: recipient dms list returned [] there too, and the
p-tag path dispatched correctly.

One adapter observation from that live run, reported upstream to #71610 (now tracked against the merged #73610 adapter)
rather than patched here: messages sent with buzz messages send into a DM
conversation carry only the h tag — the structural recipient p-tag that
the classification keys on is added by the Buzz desktop client, not the
relay. CLI-originated DMs therefore never latch. Suggested follow-up in the
adapter: treat "conversation named DM with empty description AND sender ≠
self" as a weaker classification signal, or ask block/buzz to stamp the
p-tag relay-side.

Relationship to multiplex_profiles and #70326

Upstream now has three per-something systems that touch connections and
credentials:

System	Unit	Credential surface
gateway.multiplex_profiles	profile (HERMES_HOME)	per-profile .env + secret scopes
#62944 agent registry	agent (in-process)	api_key_env (LLM) — now also <platform>.nsec_env (this PR)
#70326 tool policy	agent/tool	n/a (authorization, not identity)

This PR deliberately does not unify them. It reuses their conventions
(name-not-value credentials, fail-closed scopes, shared fingerprint salt so
either system refuses a credential the other has claimed) so that a future
unification — "a connection binding is (owner, platform, credential-ref),
where owner is a profile or an agent" — is a refactor, not a migration.
Flagged in gateway/agent_platforms.py's module docstring. Per-agent tool
policy (#70326) composes orthogonally: this PR decides which agent a
message belongs to; #70326 decides what that agent may do.

Files changed (on top of #62944 + main's #73610 adapter)

• plugins/platforms/buzz/adapter.py — private_key_env resolution
  (fail-closed), agent-scoped settings, per-agent log names
• gateway/agent_platforms.py — new: binding builder + secret resolution +
  fingerprints
• gateway/run.py — startup/reconnect/teardown for per-agent adapters
• gateway/authz_mixin.py — outbound resolution: agent-owned adapter wins,
  declared-but-down binding fails closed
• gateway/platform_registry.py — create_adapter(..., skip_check_fn=)
  opt-out for per-agent instances (see "Found in production" below)
• website/docs/user-guide/messaging/buzz.md — multi-agent section +
  provisioning checklist from the production deployment
• tests/gateway/test_buzz_multi_agent.py,
  tests/integration/buzz/test_live_relay_multi_agent.py — see below

Found in production: the plugin check_fn gate vs per-agent-only configs

This branch has been deployed to a live gateway running 11 per-agent Buzz
identities with no shared platform credential (self-hosted relay). That
deployment surfaced one real gap: plugin check_fn hooks are no-arg and
read process-wide env (BUZZ_RELAY_URL + a resolvable shared key), so a
gateway configured only through agents.<id>.buzz.nsec_env had every
per-agent adapter refused at the registry gate — with only the misleading
CLI install hint in the log. The fix: the per-agent startup path passes
skip_check_fn=True to platform_registry.create_adapter — justified
because resolve_binding_secret() has already proven the credential by
name before an adapter is requested, and validate_config (which receives
the instance config and understands private_key_env) still runs, so
genuinely unconfigured instances still fail closed. Covered by two new unit
tests. Everything else in the design survived production contact unchanged:
mention routing, per-recipient DM classification, reply-identity, and the
fail-closed credential rules all behaved as specified under 11 concurrent
identities.

Test evidence

Unit + regression (mock relay only, no network):

$ pytest tests/gateway/test_buzz_adapter.py tests/gateway/test_buzz_multi_agent.py \
    tests/integration/multi_agent tests/gateway/test_agent_routing.py \
    tests/gateway/test_attach_agent_id.py tests/gateway/test_gateway_config_multiagent.py \
    tests/gateway/test_profile_resolution.py tests/gateway/test_profile_overrides.py \
    tests/gateway/test_multiplex_profile_authz.py tests/gateway/test_restart_notification.py \
    tests/gateway/test_api_server_multiplex_secret_scope.py -q
267 passed

(Re-run after the rebase onto main with #73610's bundled adapter.)

• feat(gateway): Buzz (Block/Nostr) platform adapter — bundled plugin (salvage #71610) #73610's adapter tests (63): unchanged, passing (adapter changes are
  backward-compatible by construction).
• feat: single gateway, multiple agents — rebased onto current main (supersedes #25660) #62944's multi-agent suites (routing, isolation, session identity,
  concurrency, back-compat) + multiplex-profile suites: passing.
• 28 new unit tests: credential resolution (incl. the no-shared-key
  fail-closed case), binding construction (missing/duplicate nsec_env),
  identity routing (mention → owning agent only; per-agent
  require_mention; DM p-tag per recipient), outbound fail-closed
  resolution, runner wire-up, and the registry skip_check_fn gate
  (bypass creates the adapter; validate_config still fails closed).

Live relay (self-hosted Buzz relay, three freshly minted throwaway member
keys; skip-unless-env — BUZZ_RELAY_URL + three BUZZ_TEST_*_NSEC vars +
buzz/nak binaries — and marked integration, so default CI never runs
it):

$ pytest tests/integration/buzz/test_live_relay_multi_agent.py -m integration -q
1 passed

The test runs two real BuzzAdapter connections in one process and
verifies: @AgentA <nonce> in a shared channel dispatches on A's
connection only, stamped agent_id="agent_a", mention stripped; a p-tagged
DM dispatches on B's connection only (chat_type="dm",
agent_id="agent_b") with recipient dms list empty on this relay (i.e.
the #2897 fallback path is what actually ran); and B's reply is confirmed
on-relay as authored by B's own pubkey.