[Bug] Cross-session SendMessage to native-Windows silently fails to ingest despite success response

Bug Description
Title: Cross-session SendMessage to a native-Windows session silently no-ops — success:true + identical Remote Control echo, but the message is never ingested

Environment: Sender: Claude Code 2.1.233, macOS. Target: native-Windows Claude Code session connected via Remote Control (same account). Control peer: macOS Claude 2.1.234, also via Remote Control.

What happens

• SendMessage to the native-Windows Remote-Control session returns success:true.
• The message renders on the Remote Control web/mobile view of that Windows session — identically to the working macOS case.
• But the native-Windows local session never ingests it: it doesn't appear in the local terminal transcript, no turn starts, no action, session stays idle. Repeatable across multiple sends.
• Control: the same send to a macOS peer delivers, is ingested, and the peer replies. And the inbound message shows on the RC view in both cases.

Root cause (likely): cross-session local ingestion is macOS/Linux-only (Unix /tmp socket inbox); native Windows lacks that local inbox path, but the Remote Control relay/display path is platform-agnostic — so the message is displayed but never delivered locally. (Note: Windows has supported AF_UNIX since 2018, so this is an implementation gap, not an OS limitation.)

Why this is a footgun (the actual issue): there is no signal distinguishing "delivered to a session that will ingest it" from "displayed but will never be ingested." Both the sender's success:true and the RC echo look identical to the working case. A user reasonably concludes the message was delivered when the target Claude will never see it — a silent, success-looking failure.

Suggested fixes (any one helps)

1. Have SendMessage distinguish "queued to relay" vs "delivered to an ingest-capable session," and warn/error when the target can't ingest (e.g., native Windows).
2. Mark un-ingestable inbound messages in the Remote Control view ("this session can't process cross-session messages").
3. At minimum, warn at send time when the recipient is a native-Windows session.
4. Best of all: add the cross-agent messaging feature to native Windows!

Environment Info

• Platform: darwin
• Terminal: Apple_Terminal
• Version: 2.1.227
• Feedback ID: 9ab6835e-5563-44af-9792-e684f3f17a8c

Errors

[]