Fix shared agent mentions

[benclink]

What changed

• Allow bot-role members of the current channel into mention autocomplete even when the current user does not own the agent.
• Keep the existing relay response-policy check as the authority for whether that agent may be invoked.
• Add unit and desktop browser regression coverage for a non-owner mentioning a shared agent configured to respond to anyone.

Root cause

The composer discarded every agent identity outside the current user's managed-agent list before evaluating channel membership and the relay response policy. Shared users therefore saw plain @Agent Name text instead of a resolved mention with the agent pubkey tag.

User impact

Channel members can discover and mention shared agents that are bot members of the channel. Owner-only and allowlist response policies remain enforced by the existing downstream policy gate.

Validation

• just ci
• Focused mention eligibility unit test
• Focused Playwright mention-autocomplete flow

[tonic20]

Reviewed against main HEAD (acfbb1b) — this is the correct, minimal fix for #2349.

The isAgentIdentityMentionable = managed || (isMember && role === "bot") gate admits in-channel bots to the candidate stage while leaving shouldHideAgentFromMentions (and the relay respond-to policy) as the authority, so owner-only / allowlist agents stay enforced downstream. Tracing it through the real eligibility functions for two scenarios:

QUINN (relay-only, allowlist incl. viewer, NON-member) — expected HIDDEN
  #2333: HIDDEN   (preserves the existing "relay-only agents stay hidden ... even when allowlisted" test)
OMAR  (member bot, respond_to anyone, shared channel) — want SHOWN
  #2333: SHOWN

This also preserves the case the alternative #2314 regresses (deleting the pre-filter outright surfaces allowlisted non-member relay agents — details in #2349). And it's the only one of the two with unit + e2e regression coverage.

I also confirmed a live external-Hermes repro that this fixes (in #2349). Looks ready on the merits — could this come out of draft so it can get a maintainer review and merge? Thanks for the clean test coverage.

[andydoucet]

Production repro on 0.5.3 (latest release), and this patch applies cleanly to the desktop-v0.5.3 tag.

Setup — the always-on-Mac-mini topology this PR is for:

• Mac mini: 17 managed agents, all respond_to: anyone, all bot members of #general, hosted relay.
• MacBook (second machine): same community. Agents confirmed alive from the mini side and answering DMs from the laptop.
• Laptop @ autocomplete: offers only the agents that machine manages locally. Not one mini-hosted agent appears, at any point, under any configuration.

Things we tried that do not work, in case it saves someone else the day it cost us:

1. Setting respond_to: anyone on every agent — necessary but irrelevant; addCandidate drops non-locally-managed agents before shouldHideAgentFromMentions is ever reached, exactly as described above.
2. Creating a second identity for the laptop (so it manages nothing). This makes it strictly worse: the picker then offers nothing but the fresh Fizz/Honey/Bumble roster that the new install mints ([Bug] Second Desktop install creates duplicate agent identities, inflating channel membership #2648), and the mini's agents remain invisible.
3. Removing the laptop's local agent records. Every subsequent @mention attempt re-minted a new local instance for the persona and failed to spawn it — four dead Gemma identities in one afternoon, all now permanent members of #general with identical display names. Deactivating the personas locally did not stop the minting.

The last one is worth flagging on its own: while the picker only offers locally-managed agents, a user whose agents live on another machine is pushed toward exactly the workaround that pollutes the channel roster with dead same-named identities (#2648, #3639). The mention path and the duplicate-identity path compound each other.

DMs work fine from the laptop throughout, as others have noted — which makes the inconsistency very visible to end users: the same agent is reachable in a DM and unmentionable in a channel it belongs to.

Verified this PR against the desktop-v0.5.3 tag: git apply is clean, no conflicts.

Also worth confirming from a multi-user angle: this blocks the shared-community story, not just multi-device. A community owner hosting agents for other members can't have those members mention them from Desktop at all — the owner sees the agents, nobody else does. Mobile has no such restriction, so the same person can tag an agent from their phone and not from their Mac.

Happy to test a merge candidate on the two-machine setup and report back.