feat(cli): add agents publish-profile subcommand

[cheoljoo]

Problem

Buzz Desktop's @-mention picker only considers pubkeys present in managedAgentPubkeys or in the relay agent directory (kind:10100, queried via list_relay_agents / agentAutocompleteEligibility.ts). A buzz-acp process launched by hand (not through Desktop's Managed Agent flow) never publishes that event, so it's invisible to @-mention no matter how it's added to a channel.

What this adds

buzz agents publish-profile — signs and submits a kind:10100 agent-profile event by hand (name, channel_ids, respond_to/respond_to_allowlist, channel_add_policy). This is the same event shape Managed Agents already produce, just constructable by any identity instead of only through Desktop's UI.

Verified against a live relay: a headless agent given a profile this way does show up in @-mention and is triggerable, exactly like a Managed Agent would be.

Testing

• cargo test -p buzz-cli --lib — 343 passed (includes updated subcommand_names_are_stable / subcommand_counts_are_stable golden tests for the new subcommand)
• cargo clippy -p buzz-cli --all-targets --all-features -- -D warnings — clean
• cargo fmt --all -- --check — clean
• Manually verified end-to-end against a running relay: published a profile for a hand-launched buzz-acp identity, confirmed it appeared in Desktop's @-mention list and correctly triggered a response.

Related

Split out of a larger relay-supervisor change (a separate PR/issue) — this piece is independently useful for anyone running a headless (non-Managed) agent today, so it stands alone.

[wolfyy970]

This command is useful, but the current defaults do not deliver the behavior it promises.

• respond-to=allowlist defaults to an empty allowlist. The command succeeds, but Desktop treats that profile as explicitly non-invocable and hides it from mentions. Buzz ACP would reject the same runtime policy.
• channels set-add-policy writes sparse content to the same replaceable kind 10100. Running it later erases this profile; running publish-profile later overwrites that policy. These commands need one canonical whole-state writer.
• Kind 10100 is community-visible. This publishes channel IDs and exact allowlisted pubkeys, so the disclosure needs to be explicit. I would keep this as local instance advertisement, not access-policy or portable-definition authority.

Please validate and normalize the UUIDs and pubkeys, require a coherent trigger policy, bound the status values, and add event-level tests for mention eligibility, auth-tag signing and replaceable overwrite behavior.

[wolfyy970]

The goal is useful: a headless agent needs one supported way to advertise its live instance to Desktop. This head does not deliver that safely yet.

• The command succeeds with respond_to=allowlist and an empty allowlist. Desktop then excludes the agent from mentions, while buzz-acp rejects the same configuration at startup. Require a non-empty validated allowlist or choose a default that matches actual runtime policy.
• Kind 10100 is queried as community-wide profile state. respond_to_allowlist publishes the exact permitted pubkeys, which is target-local access policy. Keep that out of the public profile.
• buzz channels set-add-policy already replaces kind 10100 with only channel_add_policy. Running either command after the other erases fields. #5530 also constructs this event independently.

I would define one canonical profile model and builder shared by every writer, then make partial updates preserve the complete profile. Validate status, channel UUIDs and normalized 64-hex pubkeys. Tests should cover defaults, exact signed content and both writer orders.

[ScaleLeanChris]

Independent validation on head 3eb65446a9510ad08bdc756e4ae86fdc1a5c7590:

• Existing cargo test -p buzz-cli --lib passed: 343 tests, 0 failures.
• Built the candidate CLI and published a real profile for a stock Hermes Buzz gateway named Maximus. I used explicit safe values rather than the problematic defaults: respond_to=anyone, one valid channel UUID, status=online, and channel_add_policy=owner_only.
• The ScaleLean relay accepted profile event 9103adb6711438a81a56df35ad6183bda1b92882582b5322c8bf4e54e627aaeb.
• A separate Hermes gateway hosted on Fly.io then sent @Maximus from that channel. The signed send resolved Maximus's pubkey, Maximus received it, and replied in the thread with the exact requested token. Request event: 03df4c8cb8e1ab3163e163f5ff549d827cd325d5ef8df792a9e66a272605a43f; response event: 6358064afcca4c58ae0f04dd6cf8d919c095c1f3d0111ec65292b6f5a883a08e.

This proves the command can sign and submit an accepted kind:10100 event in the intended headless deployment, and that the underlying Maximus/Fly routing remains healthy after the write. It does not resolve the requested-change findings about the empty-allowlist default, public allowlist disclosure, input validation, or competing whole-state writers. I also did not claim an automated Desktop autocomplete proof because the stock CLI has no read command for the directory view.