#5681 mention gate requires kind:10100 fields that nothing publishes — relay-hosted agents are un-mentionable

**Summary.** Since #5681 (`bcf353c96`), the desktop admits a non-managed agent into mention autocomplete/send only when its kind:10100 directory record's *content* carries `channel_ids` containing the current channel AND `respond_to` of `anyone`/`allowlist` (`desktop/src/features/agents/lib/agentAutocompleteEligibility.ts`, `relayAgentCanRespondInChannel`). Channel membership no longer counts — the gate went fail-open → fail-closed.

But no publisher of those fields exists anywhere in the repo:

- The only code that emits kind:10100 is `buzz channels set-add-policy` (`crates/buzz-cli/src/commands/channels.rs`), whose content is exactly `{"channel_add_policy": ""}` — no `channel_ids`, no `respond_to`, no name.
- kind:10100 is plain replaceable, so a `set-add-policy` publish also clobbers any richer record the agent may have had.
- `agents_from_events` (`desktop/src-tauri/src/nostr_convert.rs`) back-fills `channel_ids: []` and leaves `respond_to` absent → `null` → every relay-hosted agent is denied.
- The desktop e2e suite doesn't catch this because the mock bridge fabricates rich `RawRelayAgent` records (`desktop/src/testing/e2eBridge.ts`) instead of exercising the real conversion.
- When content lacks `name`, the fallback label is the full npub, so the agent can't be found by typing its name either.

**Impact.** Any headless/relay-hosted agent (ACP harness in a container, `buzz-agent`, sprig) is structurally impossible to @-mention from the desktop — even when it is a channel member with a valid NIP-OA-authenticated kind:0 owned by the community owner.

**Repro.** Run any agent via the ACP harness against a relay (no local managed-agent definition); publish its kind:0 (`buzz users set-profile`) and a 10100 via `buzz channels set-add-policy`; open the desktop as the owner and type `@` in a shared channel → the agent never appears, and a pre-typed mention is stripped at send.

**Suggested fixes (complementary).**
1. A CLI publisher for the full directory record. We have a working `buzz agents set-directory` (read-merges the existing record, preserving `channel_add_policy` — which `handle_agent_profile` in the relay requires — derives `channel_ids` from the agent's kind:39002 memberships, name from its kind:0) running in production; happy to PR it.
2. Consider a membership-informed fallback in the gate (e.g. channel member + valid NIP-OA owner on kind:0 ⇒ mentionable), or at least an owner-visible diagnostic.
3. The ACP harness could publish/refresh the record on boot — it already knows its channels and respond_to config.