[rileycrane]

Summary

A hosted agent (one that a provider runs, not this device) wakes only for a message whose p tag names it. The desktop app added p tags only for explicit @mentions, so a plain desktop DM to a hosted agent never woke it. The mobile app already tags a DM's partner.

This PR adds ["p", <agent>] to new messages and thread replies in a one-to-one DM whose other member is an agent.

• The partner comes from the existing unmentionedRecipients(channelId).
• "Agent" uses the profile's existing isAgent signal: an owner attestation (auth tag) or a declared agent flag.
• The tag goes through the existing mentionTags. Deduplication with explicit mentions, the 32-recipient cap and validateMentions all still apply.
• A mention normally needs a connected live stream, so the app knows its membership list is current. The DM partner is exempt from that one check: they are addressed by every message in the DM, so a plain message still goes into the send queue while the stream reconnects. The cached membership must still list them, and before publishing, the app still reads the membership fresh and refuses the message if the partner has left. Anyone else mentioned still needs a connected stream.
• A human partner is never tagged. A p tag counts as a mention, so a person would be notified when they don't expect it.
• Edits, reactions, group DMs and channels are unchanged.

directMessages.open now loads a one-to-one partner's profile before it returns. Without this, the first message sent from New Message had no tag: the New Message picker reads people outside the shared profile cache, and opening the DM confirmed membership only. If the profile read fails, the DM still opens and that message is sent without the tag, as before this PR.

Related: #2478 adds the Bestie tab for hosted agents.

Notes for review

• Push notifications. The relay sends at most one push per device per event. The new tag names the agent, not the sender, so the sender isn't notified of their own message. We checked this by reading the relay and mobile push code, not with a live test.

Testing

• messages-dm-agent.test.ts (new): an agent partner is tagged on send and on reply. A human partner is not tagged. An explicit mention is not tagged twice. Group DMs and channels are unchanged. The cap still applies.
• mentions.test.ts: on a real session with the live stream reconnecting, a plain DM message to an agent is queued and published with the tag, a message to a partner who has left is refused before publishing, and a mention of anyone else still requires a connected stream. The first case fails without the fix.
• direct-messages.test.ts: starts with an empty profile cache, then runs open → first send on a real session. An agent partner gets the tag and a human partner doesn't.
• Full vitest run: all pass except browser-host/media-preparation.integration.test.mjs (tiled HEIC dimensions, local ffmpeg). It fails without this change too.
• typecheck and lint are clean.
• Manual check with a hosted agent: a plain desktop DM with no @mention wakes it, and it replies.

🤖 Generated with Claude Code

[kazemek21]

I reviewed the PR and went through the Nexus review-tracker notes. Approving with the non-blocking reconnect comment below.

Posted by Codex (gpt-6.1-sol) on behalf of kylez

[kazemek21]

[P2] Preserve plain DM queueing while the live stream reconnects

When an established two-member DM has a cached agent profile and its live stream is reconnecting, this implicit recipient reaches validateMentions, which throws because liveSnapshot.status is not connected. A plain send/reply previously passed an empty mention list and entered the durable outbox; now it fails before enqueueing with a mention-specific error even though the user added no mention. Could we preserve durable enqueueing for this implicit recipient while retaining fresh membership validation before publication? A session-level reconnect regression case would cover the distinction.

Posted by Codex (gpt-6.1-sol) on behalf of kylez

[rileycrane]

🤖 Good catch, thanks. Fixed in 474f80d. A one-to-one DM's partner is now exempt from only the "connected live stream" precondition in validateMentions, so a plain message to an agent goes into the outbox while the stream reconnects. The cached roster must still list the partner, and publication still runs the strong roster read in preflightMentions, so a partner who has left is refused before dispatch. Mentions of anyone else still need a connected stream. New session-level cases in mentions.test.ts cover the reconnect queueing (which fails without the fix), the refusal of a partner who has left, and the unchanged check for other recipients.