Mobile mention autocomplete includes archived agent identities

[SOSANA]

Summary

An archived duplicate agent that is no longer in the channel still appears in Buzz Mobile mention autocomplete on Android. Buzz Desktop correctly hides the archived identity.

Environment

• Buzz Mobile: Android
• Paired desktop: Buzz Desktop 0.5.2 on Debian
• Agent: duplicate Kimi identity with the Codex avatar

Steps to reproduce

1. Archive a duplicate managed agent identity.
2. Confirm that the archived identity is no longer a member of the channel.
3. Open the same channel in Buzz Mobile on Android.
4. Type @ followed by the agent name.
5. Observe both the active agent and the archived duplicate in autocomplete.

Expected

Archived identities are excluded from mention autocomplete.

Actual

The archived identity remains selectable in Mobile. Desktop filters it correctly.

Notes

This appears to affect Mobile candidate assembly across channel members, the relay agent directory, or global profile search. Archiving should hide the identity without requiring deletion of its public profile.

Related: #2973

[santhoshguru]

Confirmed occurrence with impact data, channel "leisure" (154d9853), 2026-08-09/10: an archived agent ("Persephone", key 738fc88b...) kept appearing in the owner's mobile mention picker alongside the live replacement identity of the same name. Three separate mentions over two days resolved to the archived key — the published events carried only the stale p tag, so the live agent was never notified and appeared unresponsive. Owner initially assumed the agent was down.

The archived identity also survived as a channel member registration on the relay, which made it resolvable at all; after the owner removed that stale membership the member list is clean (verified via buzz channels members). Fuller diagnostics (including that agents cannot self-heal this — remove-member is owner-only) are in #2423 (comment).

Suggested fix scope: mobile autocomplete should exclude archived agent identities outright, and archiving an agent should drop (or at least flag) its channel member registrations.

[iarsuaga]

Confirmed independently in a second live multi-device deployment on Buzz Mobile for Android (observed 2026-08-10).

Live evidence

• A second Desktop/Chromebook setup had created three duplicate, same-named agent identities.
• The owner archived the duplicates and removed all three from the affected channel.
• A fresh buzz channels members read against the hosted relay showed only the active identities; all duplicate pubkeys were absent.
• Mobile still returned each archived duplicate beside the active agent when the owner typed the agent name. The stale row was labelled not in channel.
• This is not only a local-cache artifact: the removed profile returns again through relay-backed global user search. Selecting it can address a dead pubkey rather than the live agent.

Root cause in current main

At commit 538e5e113f:

1. mentionUserSearchProvider performs relay-backed kind:0 global search and returns the latest profile for every matching pubkey.
2. buildMentionCandidates treats a searched agent as eligible whenever its verified owner is the current user, even if it is not a channel member.
3. Mobile does not apply an archived-discovery filter equivalent to Desktop's isArchivedDiscovery(pubkey) before adding member, directory, or search candidates.

That combination makes an archived owned-agent kind:0 profile permanently rediscoverable by name after channel cleanup. Restarting or clearing cache may refresh the screen, but it cannot prevent the relay search from returning the profile again.

Suggested fix

Apply one archived-agent exclusion before any source is added to the candidate map:

• channel members;
• relay agent directory entries; and
• global kind:0 search results.

Preserve discoverability for non-archived owned agents outside the current channel if that remains intentional.

Regression coverage

1. Archived owned agent + retained kind:0 profile + no channel membership → omitted.
2. Active same-named channel member + archived duplicate → only the active member appears.
3. Archived agent with stale relay membership → omitted.
4. Non-archived owned non-member agent → remains eligible under the existing policy.
5. Ordinary human global search → unchanged.

This is related to the duplicate-identity lifecycle in #2648, but the picker must fail safe even when duplicate memberships have already been cleaned up.

[hstrick2000]

Confirmed on a third live deployment on 2026-08-25. This also affects the Start a new message recipient picker, not only in-channel @ mention autocomplete.

Affected Buzz Mobile version: 0.13.0

Live evidence

• The owner archived 3 Honey identities, 4 Pollen identities, and one retired Fizz identity.
• A fresh buzz agents archived read from the hosted relay still contains all eight requested pubkeys in the signed archive snapshot. The retained Fizz MacMini pubkey is not archived.
• Force-closing and reopening Buzz Mobile did not remove the archived identities.
• Opening Start a new message still shows all of the archived agents as selectable recipients.
• Reporter screenshot: Buzz attachment (the media endpoint may require Buzz authentication).

Expected

Archived agents are omitted from active recipient selection while existing DMs and historical authorship remain visible.

Actual / impact

Archived identities remain selectable when creating a new conversation. Duplicate names make it easy to start a DM with a retired pubkey and incorrectly conclude that the retained agent is unresponsive.

This broadens the required fix scope: the archived-identity exclusion should be applied to the mobile new-conversation recipient candidate source as well as mention candidate assembly.

[SOSANA]

Nudge on triage — this now has three independent confirmations across separate deployments:

• @santhoshguru (2026-08-10): archived agent ("Persephone") kept appearing in channel @ mention autocomplete
• @iarsuaga (2026-08-10): confirmed independently on Buzz Mobile for Android in a second live multi-device deployment
• @hstrick2000 (2026-08-25): also affects the Start a new message recipient picker, not only in-channel @ mentions

Any chance of getting this triaged? Happy to provide more repro details if useful.