FN-5722: suppress __SKIP__ sentinel room replies

Treat __SKIP__ room responder outputs as intentional silence so they never appear in persisted or rendered chat history.

- export ROOM_SKIP_SENTINEL and helper detection in chat orchestration
- skip persisting responder outputs that are trimmed-exact __SKIP__ sentinels
- avoid room reply failure errors when responders intentionally skip
- filter sentinel-only room messages in ChatView rendering
- add backend and UI tests covering sentinel suppression and substring pass-through
- document sentinel no-op behavior in dashboard chat room guide

Files changed:
 docs/dashboard-guide.md                            |  1 +
 packages/dashboard/app/components/ChatView.tsx     |  8 ++-
 packages/dashboard/app/components/__tests__/ChatView.rooms.test.tsx   | 16 +++++
 packages/dashboard/src/__tests__/chat.rooms.test.ts     | 80 +++++++++++++++++++++-
 packages/dashboard/src/chat.ts                     | 15 +++-
 5 files changed, 116 insertions(+), 4 deletions(-)

Fusion-Task-Id: FN-5722

Fusion-Task-Lineage: 242085fc-4b88-46c1-81aa-e398f5276fec

docs/dashboard-guide.md

@@ -165,6 +165,7 @@ Chat Rooms are project-scoped group conversations for multiple agents. They are
 - The room composer clears immediately when send is dispatched so the user gets instant feedback; on success the optimistic message is reconciled with persisted server data and the transcript is refreshed to authoritative history.
 - On mobile, room threads use the same keyboard-aware thread anchoring as direct chat, keeping the composer pinned above the soft keyboard while typing.
 - The dashboard backend now orchestrates room responders on that POST: mentioned members are routed as direct responders, additional ambient members may reply (up to the room ambient responder cap), and each assistant reply is persisted with `senderAgentId` via `chatStore.addRoomMessage(...)`.
+- Room responders can intentionally stay silent by returning the `__SKIP__` sentinel; that sentinel is treated as a no-op and is never persisted, emitted over SSE, or rendered in room transcripts.
 - If room replies cannot be generated (for example no resolvable responders or all responders fail), the POST fails with an API error (HTTP 502) instead of silently returning only the user message.
 - If room responders cannot be resolved or all room-reply generations fail, the POST now returns an error instead of silently succeeding with only the user message, so failures are surfaced deterministically.
 - Room responder prompt construction now keeps the most recent room messages verbatim and, when the room runs long, prepends a compacted summary of older history (span, participants, and key highlights) plus an explicit latest-user-message marker so replies stay thread-aware without unbounded prompt growth.