feat(cli): channels set-respond-policy publishes the complete kind:10100 in one event

[rmichelena]

Summary

kind:10100 (agent profile) is a replaceable event, and the only CLI path that publishes it — buzz channels set-add-policy — writes a content with channel_add_policy alone. Every publish through it erases the agent's respond_to, name and status, so an agent that once had a complete profile stops being mentionable after a routine policy change; and a headless agent (no Desktop) has no CLI path at all to declare its respond_to.

This adds buzz channels set-respond-policy, which publishes the whole profile in one event:

buzz channels set-respond-policy --policy <anyone|owner-only|allowlist|nobody> \
    --channel-add-policy <anyone|owner_only|nobody> --status <online|offline> \
    [--name <display name>] [--allow <hex> ...]

• --policy, --channel-add-policy and --status are required at the parser, so no invocation can drop a field by omission (a partial profile is a usage error, never a smaller event).
• --allow is required with --policy allowlist and refused with any other policy; invalid values are refused before signing.
• --name defaults to BUZZ_ACP_SESSION_TITLE, the name the harness already injects.
• Signing goes through BuzzClient::sign_event, so the NIP-OA auth tag rides on the event when BUZZ_AUTH_TAG is set (fix(relay): record the NIP-OA owner for direct members on closed relays #5581's owner mapping on closed relays depends on that).
• The deployment gate BUZZ_ACP_ALLOWED_CHANNEL_ADD_POLICIES, which set-add-policy already applies, is factored into one shared function and applied by both commands, so the second publisher cannot slip past a restriction the first one honours.

set-add-policy keeps its behaviour and its partial content unchanged; this PR does not remove it.

Why a new command rather than extending set-add-policy

set-add-policy with new optional flags would keep the erasing behaviour as its default. The failure this fixes is precisely "a field went missing because nothing required it", so the fix is a command whose parser cannot express an incomplete profile. agents draft-update --respond-to is not a substitute: it opens an owner-reviewed draft through observer frames for Desktop-managed agents and publishes nothing from a headless host.

Test plan

• cargo test -p buzz-cli — 479 passed. agent_profile_tests pin the contract: the event carries every field and exactly one auth tag naming the owner when the client has one, none otherwise; allowlist without entries refused / with entries emitted; --allow with another policy refused; invalid status/policy/add-policy/blank name refused before signing; omitting --status, --channel-add-policy or --policy is a parser error. The subcommand-count test is updated (channels 16 → 17).
• The deployment-gate test binds the production path of the new command (cmd_set_respond_policy) and fails when the gate call is removed — checked by removing it, not by watching it pass.
• cargo fmt -p buzz-cli -- --check, cargo clippy -p buzz-cli --all-targets -- -D warnings clean.
• In production use on a closed relay since 2026-08 (an earlier cut of this command, without --status, has run on one host since 2026-08-11; this complete form since 2026-09-15 for a headless OMP agent whose Desktop mention eligibility and activity log depend on the complete 10100). Rebased on main@6dfd145cd.

Companion: #7699 (owner-side compute_auth_tag no longer takes the owner secret on argv).

🤖 Generated with Claude Code

[github-actions]

🔐 Codex Security Review

Status: review required for the current range.

The current range is 6dfd145cde4bf0d45091de1cc5e6c7e3462d5703...24b1c8ee01807e6fae8dd12f390cb2d31fa12d25.
A new review must complete for this exact range. When manual authorization
is required, a Block organization member must comment exactly
@buzz-security-review 24b1c8ee01807e6fae8dd12f390cb2d31fa12d25 to authorize a new review.
Any previous review applies only to its recorded range.