A friend's Bot picked from the @ menu is inserted as a bare handle, so the bubble shows chief.selftestb2.home while the preview says @Chief #967

Observed in a real-browser run on 311e3f60: with two friends and multi-message threads, picking a friend's Bot from the @ menu inserts its bare handle, so the sender's own bubble reads chief.selftestb2.home with no @ and no display name — while the sidebar preview for the same message reads @Chief.

Reproduced on 2ab9e392 with real functions and a fake roster (a just-added friend: present in roster.remoteBots, no 1:1 chat opened yet).

Two layers, both wrong

1. The @ menu inserts the handle, not a name.

• core/src/client/flybot-registry.js:137-142 remoteMentionRows(): text: \${bot.handle} `— the inserted text is the handle, no@`, no display name.
• core/src/client/at-menu.js:57-68: in a Bot's chat the roster's chat row gives way to the remote member row, and the comment says it plainly — "which inserts its handle" (:62). In a room, faces are offered by title but the inserted text still comes from remoteMentionRows (:64).
• A second insertion point exists and must not be missed: plugins/social/client.js:3356 builds a 1:1 row with value: \${friend.handle}`. Fixing only flybot-registry.js` leaves the 1:1 path broken.

2. The bubble's name table never reads the remote roster.

• core/src/client/user-message.js:36-47 mentionableBots takes names only from roster.bots (remote records of an already-open chat) and from room participants — it never reads roster.remoteBots.
• So userTextParts (:88-107) cannot cut out that span, @handle falls through whole to :108 ui.projectUserText, and DSH draws it as a file reference: bare coder.selftestc.home, no @, no name.
• The sidebar preview formats the same token through core/src/shared/remote-label.js friendBotTitle() (core/src/client/text.js:36 nameMentions reads roster.remoteBots), which is why one surface says @Coder and the other says the handle.

Routing is not broken: core/src/host/hooks.js:889-895 matches the handle from remoteMembers.list() and delivers. This is a display defect only.

Expected

One vocabulary on every surface. The @ menu inserts the label people read — @Chief, or @Chief (owner) when two friends have a Bot with the same name — and the message shows that label as a chip in both the sender's and the receiver's bubble. The handle stays the routing key underneath; it is not the visible text.

Fix direction

mentionableBots must read roster.remoteBots too, with mentionLabel coming from friendBotTitle(); and the menu rows and the bubble must share one alias generator, so the menu cannot insert a token the bubble fails to recognise. Do not write a third copy of the naming rule.

Acceptance

1. A just-added friend (in roster.remoteBots, no 1:1 chat open) picked from the @ menu inserts @Coder (display name), and the sent bubble renders it as an @ chip, not a bare handle — both from flybot-registry.js and from the 1:1 row at plugins/social/client.js:3356.
2. The sidebar preview and the bubble show the same words for that message.
3. Two friends with a Bot called Chief: the chip shows a disambiguating label (owner or home), and the send still routes to the handle the row carried — no ambiguity at the transport.
4. Pasting a bare handle still routes as it does today (the raw path is not removed), but a bare handle inside a message is not silently rewritten.
5. Routing is untouched: a delivered line still reaches the friend's Bot by handle through hooks.js:889-895, pinned by a case.
6. A room line that mentions a seated friend's Bot keeps routing on the same token the room uses today (at-menu.js:94); this issue must not change room routing.

Red proof

On 2ab9e392, a unit case over a roster with one remote Bot named Coder (handle coder.selftestc.home, no open chat): mentionableBots returns only ["Chief"], the inserted text is the bare handle, and the bubble falls through to projectUserText — three red assertions. The preview assertion (@Coder) passes today, which is exactly the inconsistency.

Dedupe

#963 is the look bleeding through a name-keyed chip rule; #389/#502 are sidebar naming and card wording. This is the insertion text and the bubble's own vocabulary — a different layer, and fixing #963 alone would not fix it.

Notes

Do not fold this into #963: that one keys the chip by id, this one decides what text is inserted and which roster the bubble reads. A fix that only changes the chip colour would leave chief.selftestb2.home in the bubble.