fix(desktop): give Hermes scoped Buzz publication

[svndco]

Summary

• promote Hermes from preset-only metadata to a known ACP runtime
• inject buzz-dev-mcp with MCP hooks into every Hermes-managed agent spawn
• preserve Hermes discovery, normalized args, reserved runtime ID, and document the tier change

This fixes Hermes replies that rendered @Name text but could not use the credential-scoped buzz messages send path, leaving the signed Nostr event without recipient p tags.

Originating Buzz channel: 6a7c32c8-772e-43b8-8468-3a21f468a611

Verification

• just desktop-tauri-test
• just desktop-tauri-clippy
• cargo fmt --all -- --check
• git diff --check

[ScaleLeanChris]

I tested this PR at 3a53613c3 together with #5856 and the current #2462 Project-delivery branch against an isolated relay and the stock local Hermes ACP adapter (hermes-agent 0.20.0).

The scoped MCP server registered correctly and received the Buzz credentials, but Hermes still chose its native terminal tool for the prompt's buzz issues comment command. That terminal resolved an older global buzz binary, so the command failed and Hermes correctly refused to publish an unattached fallback. In other words, the credentials were in the right place, but the prompt did not tell Hermes which shell owned them.

I added a two-line base-prompt instruction to route every buzz command through buzz-dev-mcp when that shell is available. On the next real run Hermes used tool_describe and then mcp__buzz_dev_mcp__shell; the relay recorded exactly one signed kind:9 response with the expected channel h, issue e, and repository a tags. The same run also published the #5856 kind:10100 routing profile. One Hermes prompt, one attached response. The focused agent-profile test and the relay-backed #2462 regression both passed.

Helper commit: ScaleLeanChris@b00b2368e

I did not open a competing PR. Please cherry-pick if this fits your branch. This keeps Hermes on the managed road instead of taking the old PATH home.