[BUG] Dispatch: desktop pane renders no messages — sessions-bridge drops every user echo ("empty inboundUserMessages FIFO")

## Summary

Dispatch works end-to-end — messages sent from the mobile app reach the local agent, are processed, and are answered — but **the desktop Dispatch pane stays completely empty**. No user message and no assistant reply is ever painted. From the desktop it looks like Dispatch is dead; from the phone it looks like it is talking to something invisible.

The cause appears to be that `sessions-bridge` discards the user-message echo that would render the turn in the desktop UI, misclassifying it as a post-compact re-emit.

## Environment

| | |
|---|---|
| Claude Desktop | 1.44121.4.0 (x64, MSIX / Microsoft Store package) |
| Claude Code (bridged SDK) | 2.1.258 |
| OS | Windows 11 Pro 26100 |
| Plan | Max |
| Agent runtime | Cowork Linux VM (`CoworkVMService` running) |

UUIDs, session IDs and paths are redacted below as ``, ``, ``, ``.

## Steps to reproduce

1. Pair Dispatch between Claude Desktop (Windows) and the mobile app.
2. Send a message to the Dispatch thread from the phone.
3. Observe the phone receives a normal reply.
4. Observe the desktop Dispatch pane — it remains empty.

## Expected

The turn (user message + assistant reply) renders in the desktop Dispatch pane, matching what the phone shows.

## Actual

The desktop pane shows no messages at all. `main.log` logs a dropped echo once per message:

```
08:41:53 [info] [sessions-bridge] Received user message for session (2 chars)
08:41:54 [info] Starting local session local_ditto_ in
08:42:07 [info] [sessions-bridge] Dropping user echo with empty inboundUserMessages FIFO
for session (likely post-compact re-emit)
08:42:08 [info] [sessions-bridge] Query completed for session (pendingTurns=0, isError=false)
08:42:08 [info] [sessions-bridge] Session turn completed, keeping transport open for follow-ups
```

This repeats exactly once per message — three messages produced three drops (08:42:07, 08:44:54, 08:45:44), each immediately before a successful `Query completed (isError=false)`.

Note the "likely post-compact re-emit" attribution looks wrong here: this was a **freshly created session** (`Created session (trigger=start)` at 08:40:15), and the drop occurs on the very first message of that session. No compaction had taken place.

## Evidence that the messages are genuinely processed

The on-disk agent transcript contains all three turns, so only the UI render path is affected:

```
local-agent-mode-sessions///agent/local_ditto_/.claude/projects/.../.jsonl

[2026-09-03T22:42:04Z] user: hi
[2026-09-03T22:42:08Z] assistant: Sent.
[2026-09-03T22:44:53Z] user: where is this session?
[2026-09-03T22:45:01Z] assistant: Answered.
[2026-09-03T22:45:43Z] user: 1
[2026-09-03T22:45:49Z] assistant: Answered.
```

`bridge-state.json` likewise recorded all three message UUIDs in `processedMessageUuids`.

## Notes

- The bridge itself is healthy: `Environment registered`, `remote-tools-device authenticated`, `remote-control bridge_state: "connected"`.
- This is distinct from the "desktop appears offline" reports (#45937 and its duplicates) — here the desktop is genuinely online and serving turns; only the desktop's own rendering is broken.

Start by tracing the sessions-bridge handler that emits "Dropping user echo with empty inboundUserMessages FIFO" and compare its fresh-session path with the post-compact re-emit path. Reproduce with a newly created session and verify that both user and assistant turns render in the desktop Dispatch pane without dropping the user echo.

Escrito por el modelo de indexación a partir del texto del issue.