fix(desktop): distinguish duplicate agent devices

[wesbillman]

Summary

• distinguish same-name owned agents by management provenance: managed here for Desktop-managed identities and managed elsewhere for same-owner relay identities
• show provenance only when same-name suggestions collide, alongside each identity's short npub
• preserve exact-pubkey selection and keep unique-agent autocomplete unchanged
• add a composed mock-bridge regression covering relay owner propagation, rendered labels, keyboard/pointer selection, and outbound mention pubkeys

Testing

• focused mention suggestion mapping and label tests
• composed Desktop E2E passes for both same-name identities and exact-pubkey routing
• causal mutation verified: replacing the relay candidate's ownerPubkey with null makes the composed E2E fail on the managed elsewhere assertion
• pre-push Desktop checks: Biome, TypeScript, file-size ratchet, and 5,103 Desktop tests

Manual test

With two same-name owned agents visible in a channel, type @<name>. Duplicate rows identify the identities as agent · managed here and agent · managed elsewhere, include distinct short npubs, and selecting either routes the mention to that row's exact pubkey.

[jedwards27]

:bot: Jude’s code review agent

Reviewed exact head fe718f3661f9e704e7a95b3e43064353f3b7f638 against base 203735f15aa2de04320dbfe1c638675da6a2e004.

Request changes

Major: this device is asserted for remotely deployed managed agents

useMentions marks every ManagedAgent as isManagedAgent: true, and mapMentionCandidateToSuggestion translates that flag directly to agentDevice: "this". That is not equivalent to device locality: ManagedAgent.backend also supports { type: "provider" }, and the existing run-location contract explicitly resolves provider backends as remote (desktop/src/features/agents/lib/agentAccessWarning.ts:15-20). A provider-backed agent therefore renders as agent · this device during a same-name collision even though it runs on a server.

That label is a locality assurance at the exact point where the UI is helping the user select a cryptographic identity. It can lead someone to choose an agent expecting this machine's files/accounts/tools when the process is remote. The short npub helps distinguish keys, but it does not make the plain-language locality claim true.

Please either:

• derive this device only from agent.backend.type === "local" and represent provider/relay-only provenance truthfully; or
• rename the labels to facts the data actually establishes, such as managed here / managed elsewhere.

Cover local managed, provider-backed managed, same-owner relay-only, and unknown-provenance cases.

Major: the new tests do not protect the production wiring

The behavior depends on useMentions propagating agent.ownerPubkey from the relay directory (desktop/src/features/messages/lib/useMentions.ts:342-354). The mapping test fabricates ownerPubkey, and the label test fabricates agentDevice; neither traverses relay result → candidate coalescing → suggestion → rendered duplicate row → selected pubkey.

A causal mutation confirms the gap: changing only ownerPubkey: agent.ownerPubkey back to ownerPubkey: null leaves all 7 added tests passing. Please add a composed component/mock-bridge workflow with two same-name, same-owner, distinct-pubkey agents. Assert truthful accessible row text and short npubs, select each row by keyboard/pointer, and verify send receives that row's exact pubkey. Mutation-check the relay-owner propagation so deleting it fails the test.

Validation

At the pinned head with a clean worktree:

• just desktop-test: 5,103/5,103 passed.
• just desktop-typecheck: passed.
• just desktop-check: passed, with only unrelated existing diagnostics outside this five-file PR diff.
• Added focused tests: 7/7 passed.
• git diff --check HEAD^..HEAD: passed.
• Causal mutation above: 7/7 added tests still passed, reproducing the coverage defect.
• CI snapshot at review time: Desktop build, integration, relay E2E, and smoke shards 1/3/4 passed; Desktop Core and smoke shard 2 were still running.

No persistence/schema change is introduced. In the searched ownership path, relay ownership is derived from verified profile events and owner-only filtering, candidate coalescing remains pubkey-keyed, and selection/send still use the selected pubkey. Those checks do not clear the false locality claim or the missing composed regression coverage.

[mfethe1]

Heads-up on a collision — I think we are solving the same problem in the same file, and whoever lands second will hit it.

#6259 ("name the computer an agent lives on") adds to MentionSuggestionCandidate:

  ownerPubkey?: string | null;
+ deviceLabel?: string | null;
+ isManagedAgent?: boolean;

This PR adds isManagedAgent?: boolean to the same type, in the same position, and derives agentProvenance where #6259 derives deviceLabel + isLocalAgent. Same field, adjacent lines, same goal: telling two same-named owned agents apart in autocomplete. That is a textual conflict on the type and a semantic one in the row — shipping both puts two independent disambiguators on the same suggestion.

Worth saying plainly: this PR is the better-scoped change. It is +219/-6 against #6259's +2029/-318, it shows provenance only when suggestions actually collide, and it already has an engaged reviewer. I am not asking you to wait on mine.

The one substantive gap I would flag is that managed here / managed elsewhere is a binary, and the case where disambiguation matters most is two remote machines — both render as managed elsewhere with only the short npub separating them. A device name resolves that case; provenance does not.

So the merge I would suggest, if you agree: keep this PR's presentation and collision-only trigger, and let a device label fill the elsewhere slot when it is known — managed here when local, the machine name when known and remote, managed elsewhere as the fallback. One mechanism, one row, and the remote-vs-remote case stops being ambiguous.

Happy to do the work either way: I can rebase #6259 down to just the device-label plumbing on top of this once it lands, or hand you the deviceLabel derivation to fold in here if you would rather keep it in one PR. Your call — mainly I did not want us both to keep building on the same lines without knowing it.

[jedwards27]

:bot: Jude’s code review agent — APPROVED at exact head 14fa44ac29a0226a55ee63c885c1a54749e98f29 (base bbd20fae75ecc3bd7a83cc12a65379fac22a2b79).

The previous blockers are resolved:

• Truthful provenance: Desktop-managed identities now map to managed-here, while verified same-owner relay identities map to managed-elsewhere; the UI renders “agent · managed here/elsewhere.” This states management provenance rather than making an unsupported runtime/device-locality claim. The composed fixture deliberately covers a provider-backed Desktop-managed identity and still expects “managed here.”
• Exact-pubkey routing: the composed regression traverses mock bridge directories through production mention coalescing/mapping and duplicate-row rendering, then exercises keyboard and pointer selection and verifies each exact pubkey in the signed outbound p tag.

Risk-shaped validation at this pin:

• Full Desktop unit suite: 5,103 passed, 0 failed.
• Focused mapping/label tests: 7/7 passed.
• Composed duplicate-agent Playwright regression: passed on a freshly built, known-clean exact-head artifact, including 3/3 consecutive runs in the systems lane.
• Provenance mutation (ownerPubkey propagation removed): causally failed the “managed elsewhere” assertion.
• Routing mutation (selected pubkey replaced with a wrong fixed pubkey): causally failed the outbound mention-pubkey assertion.
• git diff --check: passed.
• GitHub checks are complete and green at this head, including Desktop Core and all Desktop Smoke E2E shards.

No material findings remain.

Residual risk is non-blocking: Playwright serves static desktop/dist, so mutation runs can accidentally use stale bundles unless artifact provenance is controlled. Reported control runs used a fresh exact-head build; contaminated intermediate runs were excluded. Native Tauri UI automation was not rerun because this change stays within mock-bridge React behavior and does not alter native IPC or OS lifecycle.