feat(cli): add 'buzz agents set-directory' kind:10100 directory publisher

[kevine-pixel]

Summary

• Adds buzz agents set-directory — a publisher for the kind:10100 agent directory record. Addresses the publisher gap in #5681 mention gate requires kind:10100 fields that nothing publishes — relay-hosted agents are un-mentionable #5869: since fix(desktop): enforce agent mention authorization at send boundaries #5681, the desktop admits a non-managed agent into mention autocomplete/send only when its 10100 content carries channel_ids and respond_to, but the only existing 10100 publisher (buzz channels set-add-policy) writes just {"channel_add_policy": …} — and, because kind:10100 is replaceable, clobbers any richer record. Relay-hosted agents were therefore structurally un-mentionable.
• The command read-merges the existing record so unrelated fields — notably channel_add_policy, which the relay's handle_agent_profile ingest requires — survive a republish.
• --name defaults from the identity's own kind:0 display_name/name; --channels-from-membership derives channel_ids from the identity's kind:39002 memberships; --no-channels supports DM-only agents; --respond-to owner-only|allowlist|anyone with --allow <PUBKEY> for allowlists (validated 64-hex, normalized lowercase).
• The NIP-OA auth tag is injected by the existing sign_event path, unchanged.

Validation

• Unit tests: merge preserves unrelated fields (channel_add_policy, unknown keys) and overwrites stale directory fields without touching a customized agent_type; subcommand stability guards updated.
• cargo clippy / cargo fmt clean; full buzz-cli test suite passes (345).
• Live-validated: 24 production relay-hosted agents republished their records with this command (each signing with its own identity + auth tag); the desktop fix(desktop): enforce agent mention authorization at send boundaries #5681 mention gate then admitted them, confirmed end-to-end by the community owner. The 3 DM-only agents published --no-channels records.

Related: #5869 (publisher gap — this PR), #5870 (directory inspection UI, separate).

🤖 Generated with Claude Code

[WifiDan]

Operator data point in support of this PR, from a self-hosted multi-tenant deployment: ~26 headless agent seats across 8 communities, all running as systemd services under a custom ACP harness rather than Buzz Desktop. None of them are mentionable, for exactly the reason this PR describes.

The measurement I think is most useful here isn't the count of missing records — #6304 already reports the "one entry on the whole relay" finding, and ours matches. It's the other half: we published a kind:10100 record by hand, from an arbitrary identity, with no owner attestation and no Desktop involvement, and the relay accepted and served it. accepted: true, read back intact, full content preserved. A broad query then showed exactly one such record on the entire relay — ours.

That seems worth stating explicitly, because it means there is no relay-side gate on publishing a directory record. The missing piece is purely a producer. Nothing about the relay needs to change, and nothing needs to know anything about which harness an operator runs.

That last part matters for this PR's chances, I think. #4144 and #4146 were closed on the principle that "Buzz core should not discover or parse a particular harness installation; adapter-specific discovery and lifecycle belong outside this repository, using public Buzz contracts." A CLI publisher is exactly that — it uses a public contract and requires core to know nothing about the harness. It sidesteps the objection rather than reopening it.

From an operator's seat, buzz agents set-directory is also the only one of the current approaches that is deployable today. buzz-node (#4597) is a much larger change and still draft; the ACP-side publishers (#5546, #6304) only help operators whose agents run under those specific paths. A CLI command can be called from a systemd unit, a provisioning script, or a cron job by anyone, whatever their harness. We'd wire it into seat provisioning the day it lands.

Happy to test against a real multi-community deployment if that's useful — we have 8 communities and a mix of client-facing and internal crews, which should exercise the --channels-from-membership and channel_add_policy read-merge paths reasonably hard.