send_message to a running session can silently fail to persist - content confirmed sent, never appears in target's transcript

Using the ccd_session_mgmt tools (list_sessions, list_events, search_session_transcripts, send_message) in Claude Code / Claude Cowork.

Repro scenario:

1. Session A (busy, long-running, 3000+ messages, multiple concurrent long background agent calls) is actively running.
2. Session B sends it a cross-session message via send_message. The tool call returns success ("Sent").
3. The user visually watches the message land in Session A's live view.
4. Later, Session A is asked directly about that message and reports "no record of it."

What I verified, not assumed:

• The message was genuinely composed and dispatched - confirmed in Session B's own transcript (the user's instruction, the send_message tool call, and its "Sent" confirmation are all there).
• The message is genuinely absent from Session A's persisted transcript - I paged through Session A's full history (3,140 messages) and ran full-text search (search_session_transcripts) across it. The original content never appears as a delivered turn. The only matches are later paraphrases by other sessions describing "the ask" secondhand - never the actual delivered message.
• This rules out a wrong-session delivery mixup (same target session ID throughout, user confirmed it was the right one) and rules out ordinary context-window scrolling (the search tool reads the durable transcript store directly, independent of what's in the model's active context - and it's not there either).

Suspected mechanism: a race between send_message's append and the target session's own conversation compaction (manual /compact or automatic, as sessions approach context limits). If the cross-session append lands while a compaction rewrite is in flight, it can render once live (matching what the user saw) without being folded into the summary that becomes the durable log going forward - making it unrecoverable afterward by either the model or the transcript tools.

Impact: send_message's success return only confirms the sender's call succeeded, not that the target's transcript durably recorded it. There's no acknowledgment loop today that would catch a dropped append at the time it happens, and no way for a session to self-audit its own full transcript (list_events/search explicitly exclude the current session), so this class of loss is currently undetectable except by an external session cross-checking after the fact - which is how this one was caught.

Ask: investigate whether send_message appends can race with compaction on the receiving session, and whether a persisted-delivery acknowledgment (rather than sender-side "Sent") is feasible.