fix(desktop): refresh agent lists when a member is added to a channel

[shaileshj2803]

Problem

Adding an agent to a channel does not make it @-mentionable there until the relay-agents query's 5-minute poll fires or the app is restarted. Repro: create a channel, add a relay agent (e.g. a self-hosted buzz-acp agent) as a member, open the composer — the agent is missing from the mention autocomplete for up to 5 minutes.

Root cause

useAddChannelMembersMutation (desktop/src/features/channels/hooks.ts) invalidates only the channel state in onSettled. It does not invalidate relay-agents / managed-agents. Its siblings already do — useRemoveChannelMemberMutation and useDeleteChannelMutation both invalidate these lists — so the omission is an asymmetry: removing a member refreshes the agent lists, adding one doesn't. Because the relay-agents query's only other refresh path is a 5-minute refetchInterval (paused while backgrounded), a newly added agent stays absent from mentions until that poll or a restart.

Fix

Invalidate managed-agents and relay-agents in the add-member onSettled, matching remove-member. A relay agent's kind:10100 discovery record only lists the new channel after the agent republishes it in response to the membership change (a moment later), so invalidate immediately and once more after a short delay to catch that republish rather than racing it.

Notes

• Matches the existing invalidation style/keys used by the sibling mutations.
• Pairs with the harness-side fix that makes externally-deployed agents self-publish and refresh their kind:10100 record on channel join (separate PR) — together they close the "added an agent, can't mention it" gap end to end.

[Chessing234]

the setTimeout(refreshAgentLists, 4_000) is never cancelled. onSuccess can fire and then the user switches community or closes the panel — the timer still lands 4s later and invalidates managed-agents/relay-agents against whatever tree exists then, which after a community switch is a different relay entirely. worth returning a cleanup, or keying the second refresh off the kind:10100 arrival instead of a delay.

4s is also a guess at how long the agent takes to republish, and the comment says as much ("catch that republish rather than racing it"). it is still a race — it just moves the losing case from "always" to "slow relay". the observer/relay path already sees the republish land; reacting to it would make this deterministic.

small one: ["managed-agents"] and ["relay-agents"] are spelled inline here, but features/agents/hooks.ts:123-124 exports relayAgentsQueryKey and managedAgentsQueryKey for exactly this. same values today, so no bug — but a literal will not follow if the key ever changes, and it will fail silently by simply not invalidating.

[Chessing234]

the immediate invalidation is clearly right — it matches the siblings at :737-738 and :825-826, and the keys check out (relayAgentsQueryKey/managedAgentsQueryKey in agents/hooks.ts:123-124 are literally ["relay-agents"]/["managed-agents"]).

the 4s follow-up rests on a premise i can't find support for. grepping kind 10100 across crates/ and desktop/, the only hits are the constant in buzz-core/src/kind.rs:87, the relay's inbound channel_add_policy handler (side_effects.rs:1172-1196), desktop's read query (agent_discovery.rs:1046), and tests — nothing in-tree publishes or maintains that record, so there's no republish-on-membership-change to catch. #5691 is open precisely to add that publisher (opt-in via BUZZ_ACP_PUBLISH_PROFILE), and #5832 would replace the reader with 30177+0+39002.

if that's right the timer never buys anything for a relay agent, and dropping it also removes an unanchored setTimeout that fires once per mutation with no unmount cleanup. desktop-managed agents come from the local store, so the immediate invalidate already covers them.

[cmyk]

Fresh real-world confirmation from the official Buzz Desktop 0.5.17 macOS release:

• An existing remote Gateway agent was removed and re-added through Add people.
• The relay recorded it correctly as a bot member.
• It remained absent from @ autocomplete after the successful add.
• Cmd-R immediately made it available.
• The subsequent structural mention completed a real external-Gateway request/reply.

This confirms the stale post-add agent-query behavior described by this PR. Since #6182 and #6224 are already included in 0.5.17, the remaining observed gap is the add-member invalidation asymmetry.

The immediate invalidation looks necessary. I agree with the existing review concern that the uncancelled four-second timer is speculative and nondeterministic. Could this PR be refreshed against current main with the minimal immediate invalidation, exported query keys, and a regression covering add-agent → immediate autocomplete?

I would prefer updating this contribution rather than opening a duplicate implementation.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Request changes: the user goal fits Buzz, but this synchronization mechanism leans against the architecture.

Buzz’s model makes relay-authored channel membership the authoritative access boundary (VISION.md: “channel membership is the only gate”). This patch instead asks Desktop to infer convergence from an agent-owned kind:10100 discovery record, then guesses when that duplicate channel list may have caught up using a fixed four-second timer in desktop/src/features/channels/hooks.ts.

That reverses the ownership boundary: membership state should flow from the authoritative membership event into discovery/mention eligibility. A client cache should not establish correctness by sleeping and rereading eventually consistent discovery metadata. It also cannot guarantee the stated result: the producer is outside this PR, publication may be disabled or delayed beyond four seconds, and a failed/no-op/human addition still launches both global refresh rounds.

Please prefer the authoritative membership path (the direction represented by #5832’s relay-authored kind:39002 enrichment) and prove the add-agent → membership-visible → mentionable journey with an integration test. If this PR remains a tactical cache fix, restrict it to one immediate invalidation after a successful, non-empty bot addition, use the exported query keys, remove the blind timer, and describe it honestly as reducing cache staleness rather than guaranteeing eventual profile publication.