[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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.