feat(buzz-acp): publish the kind:10100 relay-agent directory entry

[Schnitzel]

The problem

An agent run by buzz-acp never appears in Buzz Desktop's @ autocomplete, however healthy it is, and nothing anywhere reports why.

Desktop builds its mentionable set as managed agents ∪ relay agents (desktop/src/features/agents/knownAgentPubkeys.ts):

• managed agents are the ones the desktop holds a key for and runs itself. An agent created in the app is in this set immediately and needs no relay event at all.
• relay agents come from kind 10100, filtered by relayAgentCanRespondInChannel — the entry's channel_ids must contain the channel being typed in, and its respond_to must admit the person typing.

A harness-run agent can never be in the first set, so kind 10100 is its only route. buzz-acp never publishes one. channel_ids is then absent, agents_from_events defaults it to [], and the agent is eligible in no channel.

The failure is silent end to end: no client-side error, and a mention typed by hand goes out with no p tag, so it routes nowhere either. From the user's side a perfectly healthy bot simply cannot be mentioned.

examples/countdown-bot's README attributes mentionability to the role=bot self-add. In testing against a current relay and desktop that was not sufficient on its own; publishing kind 10100 was what made the agent appear.

The change

Publishes the entry from state the harness already holds — the channels it discovered and subscribed to, plus its own author gate — at startup, and again whenever a membership notification changes the channel set.

• only subscribed channels are advertised, so the entry never offers a mention the agent would not actually receive
• on membership change the channel set is re-read from the relay rather than trusted from local bookkeeping
• best-effort: discoverability is not worth failing a startup or dropping a membership update over, so failures are logged and execution continues
• kind 10100 is replaceable, so republishing supersedes rather than accumulating

Two new flags, so existing deployments that publish this entry themselves are unaffected:

Flag	Env
--no-publish-directory	BUZZ_ACP_NO_PUBLISH_DIRECTORY
--display-name	BUZZ_ACP_DISPLAY_NAME

name is omitted when unset rather than guessed, so clients fall back to the agent's kind:0 profile name and then its npub, as they already do. respond_to_allowlist is emitted only in allowlist mode, mirroring the inbound author gate so the people who may prompt an agent are exactly the people whose client offers it.

Testing

• 5 new unit tests on the entry body: only subscribed channels advertised, names positionally aligned with ids, allowlist only in allowlist mode, blank names omitted, output stable across builds (so a replaceable event is not rewritten without cause)
• full buzz-acp suite: 783 passed, 0 failed
• cargo clippy -p buzz-acp --all-targets clean, cargo fmt applied
• built and exercised against a live self-hosted relay, where the published entry made a previously invisible agent mentionable

Question for maintainers

Kind 10100 does not appear in any NIP under docs/nips/, unlike the other agent-facing kinds (NIP-AP, NIP-AE, NIP-AO, NIP-AA). If it is intended to stay an internal convention I am happy to adjust; if it should be specified, I would be glad to draft it. Happy to change the default to opt-in if you would rather this not publish without being asked.

[Schnitzel]

Flagging honestly that #6338 has substantially reduced the value of this PR, in case that changes whether you want it.

This publishes the kind 10100 directory entry from the harness, motivated mainly by the entry going stale: nothing republished it when the agent's channel set changed, so an agent added to a channel silently became unmentionable there. On our relay that bit four separate times in a week.

In v0.5.18 the relay-agent directory no longer takes channels from the entry at all — list_relay_agents_for_selection derives them from the relay's own kind 39002 rosters and then overwrites whatever the entry said:

agents.retain(|agent| member_agent_channel_ids.contains_key(&agent.pubkey));
for agent in &mut agents {
    agent.channel_ids = member_agent_channel_ids.get(&agent.pubkey).cloned().unwrap_or_default();
}

So the staleness problem this was written for is already solved, and better — membership now comes from the authority that owns it, rather than from a snapshot someone has to remember to refresh. On top of that, relay_agents_from_directory_events discards the kind 10100 entirely for any agent with a verified kind 30177, which is every properly provisioned agent.

That leaves this PR useful only for agents with no owner-published 30177 — a shrinking set, given v0.5.18 also requires a verified NIP-OA owner.

Happy to close it. I would only argue for keeping it if you want harness-run agents to be discoverable without owner-side provisioning, which is a product question rather than a bug. Your call — say the word and I will close, or I will rebase it if it is still wanted.

(#6098 is unaffected by all this and still stands on its own — it is about the relay never recording agent_owner_pubkey for an agent enrolled as a direct member, which silently disables its NIP-AO observer frames.)