feat(acp): self-publish kind:10100 agent profile for Desktop discovery

[shaileshj2803]

Problem

An externally-deployed agent — one running as its own process/pod and connecting to the relay over NIP-42, rather than being launched by Buzz Desktop — never appears in Desktop's @mention autocomplete. Desktop offers a relay agent (kind:10100) only in channels whose id is listed in that agent's discovery record, and nothing in the harness publishes or maintains that record. The result is an agent that is online, a channel member, and responds to CLI mentions, yet cannot be @mentioned by name from Desktop in any channel. Managed (Desktop-launched, kind:30177) agents are unaffected because Desktop sources those from its local store.

Change

Add opt-in self-registration to buzz-acp via BUZZ_ACP_PUBLISH_PROFILE=true:

• The harness publishes its own kind:10100 agent-profile on startup and refreshes it whenever it joins or leaves a channel (the membership-notification path), keeping channel_ids current with no manual bookkeeping.
• Written through the durable HTTP POST /events path (RestClient), not the ephemeral WS publish path, which silently drops replaceable events (10000-19999) when rate-gated.
• Content carries the relay-required channel_add_policy plus the descriptor Desktop reads (name, respond_to, channel_ids, capabilities, about). Descriptor fields are configured via BUZZ_ACP_DISPLAY_NAME / BUZZ_ACP_CHANNEL_ADD_POLICY / BUZZ_ACP_CAPABILITIES / BUZZ_ACP_DISPLAY_ABOUT.
• Content-building is factored into a pure, unit-tested helper (build_agent_profile_content); channel/allowlist sets are sorted so the replaceable event is stable across republishes.

Opt-in so existing deployments that do not want to advertise are unaffected.

Testing

• New unit tests for descriptor shape (required channel_add_policy, stable output).
• Verified end-to-end against a live relay: startup publish; live refresh when the running agent is added to a new channel; and an unaffected mention round-trip. Two deployed agents (Claude Code and Codex pods) then became @mentionable in freshly-created channels automatically, with no manual registration.

README updated with the new env vars and the discovery/autocomplete semantics.

[Chessing234]

all five settings are read with bare std::env::var inside publish_agent_profile, which is why the table has "Flag: —" for every row. buzz-acp already has a place for this: CliArgs with #[arg(long, env = "BUZZ_ACP_...")] feeding Config. #5703 is landing BUZZ_ACP_QUEUE_MAX_RETRIES through exactly that path right now, so the two will look inconsistent side by side.

the practical costs of the bare reads: no --flag form, no clap validation on BUZZ_ACP_CHANNEL_ADD_POLICY (a typo silently falls back rather than failing at startup), and the values never reach the startup config summary that logs relay=... context_limit=... max_turns_per_session=.... that last one matters most here — an operator debugging "why is my agent not mentionable" cannot see what the harness actually published. it also makes the builder testable only by mutating process env.

separately, #5546 and #5483 are both open on kind:10100 discovery for @mention eligibility. worth checking against those before this lands.

[Chessing234]

worth knowing before this lands: #5832 removes the consumer. agent_discovery.rs:1053 is desktop's only kind:10100 reader (the sole non-test caller of nostr_convert::agents_from_events) and that PR replaces it with 30177 + kind:0 + 39002 — if it merges first this publisher has nobody reading it. i've flagged the same collision on that side.

on shape: these five knobs are read with raw std::env::var inside publish_agent_profile, where every other buzz-acp setting is a CliArgs field with #[arg(long, env = "...")]. the cost is visible in your own README table — the Flag column is "—" for all five. they also miss the startup config summary line, clap validation, and desktop's remote-deploy plumbing (siblings get plumbed at runtime.rs:672/676 for local spawn and agents_deploy.rs:89 into policy_env for remote), so a hosted agent can't be given a display name or capabilities at all.

the validation gap is the one with teeth: channel_add_policy ships as whatever string is in the env and the relay takes it verbatim — side_effects.rs:1191 hands it straight to set_channel_add_policy with no enum check at that layer. so BUZZ_ACP_CHANNEL_ADD_POLICY=owner-only (hyphen) persists as the agent's policy and nothing reports it. a clap value_parser, or a match on the three documented values, closes that.