fix(acp): publish remote agent routing profiles

[rsnodgrass]

Summary

Remote AI coworkers can now appear in the mention picker and receive tagged messages after joining a channel or newly created DM. Previously, ACP harnesses announced presence but not the signed routing profile Desktop uses to authorize remote recipients.

Approach: Publish a replaceable kind-10100 profile from buzz-acp at startup and refresh it after membership changes, advertising the harness’s response policy and subscribed channel IDs.

What changed

File	Change
crates/buzz-acp/src/lib.rs	Publish the signed agent profile through the durable HTTP bridge; refresh it asynchronously on channel add/remove; add routing-profile regression coverage.

Test Plan

• cargo test -p buzz-acp agent_profile_advertises_the_current_routing_policy — 1 targeted regression test passed.
• cargo check -p buzz-acp — passed.
• cargo fmt --all and git diff --check — passed.
• Preflight — skipped at requester direction.

Depth: delivery behavior

The profile’s channel_ids, respond_to, and allowlist mirror the harness’s live subscription state. Membership-triggered refreshes run in the background so retrying a durable profile write cannot stall relay event processing.

Co-Authored-By: SageOx ox@sageox.ai

[ScaleLeanChris]

Live integration result for 0b2003b36 combined with #5838 and the current #2462 Project-delivery branch:

• buzz-acp started with a disposable authorized bot identity on an isolated relay.
• The relay recorded one signed kind:10100 profile with agent_type=agent, the exact authorized channel_ids, respond_to=owner-only, an empty allowlist, and status=online.
• The same identity then received one Project mention through real Hermes and published one issue-attached kind:9 reply.
• cargo test -p buzz-acp agent_profile_tests: 1 passed, 0 failed.

I found no #5856-specific code defect in this run. The only integration gap was #5838's prompt routing to the managed MCP shell, documented with a helper commit in that PR. For this profile publication path, the signed event came through loud and clear.

[wolfyy970]

A runtime-owned routing profile is the right seam for discoverability; it should stay separate from portable definition authority. I found two blockers in the current wire behavior.

1. Kind 10100 is globally queried by Desktop, so this publishes the exact respond_to_allowlist pubkeys community-wide. NIP-AP explicitly treats that list as sensitive and protects it behind the 30175 sharing gate. There is also already a second whole-state writer for this replaceable event: buzz channels set-add-policy publishes only channel_add_policy. Either command can therefore erase the other profile fields on its next write. Please use one canonical read/merge/write profile contract or a separate event boundary, and keep private allowlist membership out of the public routing advertisement.

2. Membership refreshes are detached tasks carrying cloned channel sets. A quick add/remove can complete out of order, and events created in the same second are resolved by the NIP replaceable-event id tiebreak rather than notification order. The retained profile can therefore advertise a channel the harness already left, or omit one it joined. Please serialize profile publication through one worker with a monotonic generation/timestamp and test delayed, reversed add/remove completions against the retained head.

The signed harness-owned identity and channel-derived routing direction are good; these fixes keep the advertisement truthful without turning it into hidden policy disclosure.

[rsnodgrass]

@wolfyy970 great suggestions.

Addressed the requested changes in 61bd116.

• respond_to_allowlist is no longer included in the public kind:10100 runtime routing advertisement. Remote allowlist agents now fail closed in desktop mention eligibility.
• Channel-add policy moved to dedicated replaceable kind:10101, so buzz channels set-add-policy cannot replace the routing profile. The relay routes only the new kind to the policy side effect; kind:10100 is verified by a regression test not to trigger it.
• Replaced detached snapshot tasks with one harness-owned publisher on the membership event loop. It emits monotonic created_at values; the added regression test proves the final remove remains the retained profile even if its earlier add reaches the relay afterwards.

Validated: ACP profile tests (2), relay scope/side-effect tests, CLI policy test, desktop typecheck, and the 30 focused mention-eligibility tests. Desktop lint completes with three pre-existing diagnostics outside this change.