fix: publish kind:10100 agent directory records so shared agents are @-mentionable

[jjalora]

Summary

Non-owners can never @-mention a shared agent, no matter what the owner configures — the root cause is that the kind:10100 agent directory the mention-eligibility pipeline reads has no producer. #4913 implemented and e2e-pinned the consumer side (respond_to + exact-channel authorization from RelayAgent records), but nothing anywhere publishes those records: the only kind:10100 writer in the tree is buzz channels set-add-policy, which writes a policy-only body (and, being replaceable, clobbers anything richer — #3663/#4490). On a real relay, list_relay_agents returns nothing usable, getMentionableAgentPubkeys collapses to the viewer's own managed agents, and the feature only appears to work in e2e because the mock bridge synthesizes directory entries (syncMockRelayAgentsFromManagedAgents) with no production counterpart.

Fixes #5363, fixes #4548 (commit 1); fixes #4489, fixes #3809 (commit 2). Also relevant to #2603 (composer half; the MembersSidebar add-gate is untouched), #4128, #4776, #3125, #3739, and the directory-staleness aspect of #4535.

Commit 1 — feat(acp): the harness publishes its own directory record

buzz-acp now publishes and maintains the agent's kind:10100 record. The harness is the right producer because it knows the respond_to policy it actually enforces and the channels it actually listens on — the advertisement can never drift from enforcement (a deployment that clamps --respond-to to owner-only also clamps what gets advertised, so records never promise an authorization the author gate would refuse).

• Publishes at startup (after channel subscriptions, same durable-readiness boundary as presence), debounced (2 s, abort-and-respawn like the presence heartbeat) on membership add/remove, and best-effort flips status to offline on graceful shutdown.
• Content matches exactly what agents_from_events → RelayAgentInfo → RawRelayAgent parse: name (from session_title, omitted when absent so the npub fallback engages), agent_type (normalized agent command identity), status, respond_to (the RespondTo Display literals), respond_to_allowlist (sorted), index-aligned channels/channel_ids, capabilities, channel_add_policy.
• channel_add_policy is carried forward from the current head record before every publish, so a policy set via buzz channels set-add-policy survives the republish and the relay's kind:10100 side effect (handle_agent_profile) stays satisfied. On a failed head fetch the publish is skipped entirely — never fabricate a policy.
• DM-typed and unresolved-type channels are excluded from the advertised set: the author gate rejects non-owner DMs regardless of mode and fails closed on unresolved types, so advertising them would invite mentions the harness then silently drops.
• Everything is best-effort: failures are logged and swallowed; publishing can never take the harness down. HTTP bridge (RestClient::submit_event) rather than the WS path, which silently drops non-observer events while disconnected.

With records published, stock desktop and mobile clients admit the agent through the already-pinned consumer chain (relay-only anyone agents are visible when a channel is shared, relay-only shared agents emit an outbound mention tag when selected, allowlist specs). Unit tests pin the producer schema; a new integration test (desktop/src-tauri/tests/agent_directory_schema.rs) pins the cross-crate contract from the consumer side.

Commit 2 — fix(desktop): member agents with unknown invocability stay mentionable

addCandidate ran isAgentIdentityInAllowedList before shouldHideAgentFromMentions, making the latter's documented member-agent rule ("unknown invocability ⇒ show" — the Option B comment, and its unit tests) unreachable dead code: any member agent absent from both the managed list and the directory was dropped by the first check.

This commit removes the redundant first check at that call site. shouldHideAgentFromMentions already implements the intended policy: invocable ⇒ show; non-member non-invocable ⇒ hide; member with an explicit not-invocable directory record ⇒ hide; member with no record ⇒ show. The last case is the useful fallback while a fleet's harnesses haven't (yet) published records — and once they have (commit 1 publishes for every mode, including owner-only), non-invocable member agents gain an explicit exclusion record and correctly disappear, so the stale-agent concern that motivated the stricter gate is answered by data rather than by hiding every foreign member agent. One e2e expectation is updated accordingly (stale channel-member agents … stay hidden → … stay mentionable).

This commit is separable — if maintainers prefer to keep the fail-closed member behavior from #4913, commit 1 alone fixes the shared-agent flow for record-publishing harnesses.

Testing

• cargo test -p buzz-acp (incl. 6 new directory unit tests: consumer-schema shape, respond_to literals, name-key omission, allowlist ordering, dm/unknown channel exclusion, add-policy carry-forward/defaults)
• New desktop/src-tauri/tests/agent_directory_schema.rs integration test (consumer-side contract pin)
• desktop: tsc --noEmit, biome, full unit suite, and the full mentions.spec.ts e2e suite (58 specs) with the one updated expectation
• cargo clippy -p buzz-acp --all-targets -- -D warnings, cargo fmt --check
• Manually verified end-to-end on a self-hosted relay: owner sets Anyone → harness publishes the record → a second account sees the agent in @ autocomplete in the shared channel → mention carries the p tag → agent responds. (This deployment shape — a 24/7 host running shared community agents — is what surfaced the bug.)

Notes / non-goals

• buzz channels set-add-policy still replaces the whole record (set-add-policy replaces the full kind:10100 record, hiding the agent from mention autocomplete #3663/buzz channels set-add-policy replaces the caller's whole kind:10100 agent profile, erasing name and respond_to #4490); this PR makes the damage self-healing (next harness publish restores the full record, policy carried forward) but doesn't change the CLI.
• Waking a stopped foreign agent on mention (Mentioning an agent from another machine never wakes it — agent start on mention is sender-side only #4658) and DM invocation of foreign agents (author-gate policy, pinned by test) are out of scope.
• Directory records intentionally advertise only non-DM, resolved-type channels; status is cosmetic to eligibility (presence remains the liveness signal).

🤖 Generated with Claude Code

[wolfyy970]

Publishing from the harness is the better direction. It can describe the channels and response mode the running agent actually enforces, so I would use this instead of the separate CLI writer in #5528. #5530 should reuse the same path rather than construct another profile.

Two boundaries need settling first:

• NIP-AP explicitly treats respond_to_allowlist pubkeys as sensitive. Kind 10100 is queried community-wide, so this publishes the exact access list to every member. The public directory can advertise safe routing state, but allowlist membership needs a private boundary.
• Carrying channel_add_policy forward is still a read-modify-write race. If buzz channels set-add-policy writes after the head fetch but before this submit, the harness restores the old policy. Either the harness must become the sole profile writer or directory and policy state need separate ownership.

I would also split the unknown-member fallback into its own PR. The producer fix is useful without changing whether clients show agents whose invocability is unknown.