feat(agents): add Hermes ACP and external-agent integration

[NYTEMODEONLY]

Summary

• add Hermes Agent to the Desktop runtime catalog and document local/VPS deployment
• publish complete kind 10100 directory profiles from externally hosted buzz-acp agents
• refresh those profiles after accepted membership changes
• preserve complete profiles when buzz channels set-add-policy changes one field
• derive external-agent ownership only from a verified NIP-OA auth tag
• make owner-only external agents eligible in mention and recipient surfaces
• show externally hosted agents under External agents without local runtime controls
• refresh the relay directory on focus and every 30 seconds

Root cause

Externally hosted agents could have valid identity, ownership, and channel membership while remaining absent from Desktop mention surfaces. Their replaceable kind 10100 record was incomplete, policy changes could clobber it, and Desktop did not carry verified owner identity into eligibility checks.

The new path keeps the security boundary fail-closed: Desktop ignores self-claimed owner fields and trusts only a cryptographically valid NIP-OA auth tag.

Hermes runtime design

Hermes exposes ACP over stdio through both hermes acp and hermes-acp. Desktop uses hermes-acp as the readiness probe so a base install without the optional ACP extra is reported accurately. Automatic installation remains disabled because the official ACP-extra install path differs across managed source installs and platforms; Doctor links to Hermes's official setup instructions instead.

Hermes keeps its own model/provider selection and existing ~/.hermes/config.yaml state. Buzz does not inject parallel provider configuration or replace Hermes memory, skills, or tools.

Live interoperability proof

The baseline Hermes integration was deployed on a Linux VPS with Hermes Agent v0.19.0 and Buzz v0.4.23:

• hermes acp --check returned OK
• buzz-acp initialized Hermes with its existing memory and native MCP tools
• a dedicated identity joined a Buzz channel with the bot role
• a Buzz mention reached Hermes and received a signed reply in the same thread
• the bridge runs under systemd with Restart=always
• its credential environment file has restrictive ownership and permissions

The external-directory changes in commit 464dc366 still require the commit-bound Linux package to be deployed to that VPS before the final live UI verification.

No private key, API token, owner authorization, or private relay endpoint is included in this PR.

Validation

At commit 464dc366:

• cargo fmt --all -- --check
• cargo clippy --workspace --all-targets -- -D warnings
• cargo test -q -p buzz-acp -p buzz-cli — ACP 584 unit + 9 integration; CLI 253
• cd desktop && pnpm test — 3,402 passed
• cd desktop && pnpm typecheck
• cargo test --manifest-path desktop/src-tauri/Cargo.toml --lib — 1,565 passed, 13 ignored
• git diff --check

just ci reaches Desktop's existing file-size baseline failure in unchanged desktop/src-tauri/src/managed_agents/discovery/tests.rs (1,293 lines vs 1,273 limit).

Companion Hermes documentation

• docs(acp): document Buzz host integration NousResearch/hermes-agent#69915

[peteclt92]

I tested the Hermes runtime path end to end on an Intel macOS Buzz Desktop host with the agent running persistently on Linux. Two interoperability details look worth tightening before merge:

1. Please accept the native hermes entrypoint, not only hermes-acp. The official installer produced Hermes Agent v0.19.0 at ~/.local/bin/hermes; it did not install a hermes-acp executable in the expected PATH. The verified ACP invocation was hermes acp (and, for a dedicated profile, hermes --profile <profile> acp). With commands: &["hermes-acp"], Desktop can report adapter-missing immediately after a successful official install. I suggest discovering both forms, with command-specific defaults: hermes -> ["acp"], hermes-acp -> []. hermes acp --check is also the useful readiness probe where the catalog can express command arguments.

2. Please include Python in marked managed-process recognition. The live Hermes service process was a venv interpreter running the Hermes console script (.../venv/bin/python3 .../venv/bin/hermes ... acp), rather than a process named hermes. The existing BUZZ_MANAGED_AGENT marker check keeps this bounded, so adding exact python / python3 interpreter matches would let Buzz lifecycle cleanup find the process without sweeping unrelated Python jobs. Prefixes such as python3.12 should remain rejected unless intentionally handled.

The rest of the first-class catalog shape matches the live integration well. These two points came from actual install, discovery, selection, and signed Buzz reply verification rather than static inspection.