[Fix] In-session replies disappear after a network failure

[roomote-roomote]

​Opened on behalf of @mrubens. View the task or mention @roomote-roomote for follow-up asks.

What changed

• Failed in-session Fast replies now keep the prepared prompt, attachments, model choice, and reasoning effort available behind an inline Retry action.
• Every web reply gets a stable client message ID; retries reuse it, and the server skips an already-canonical turn instead of creating duplicate work.
• A newer draft is preserved when the user edits the composer before retrying the captured failed reply.

Why this change was made

Transient client-network failures can make an in-session task submission look lost even when the original request may have reached the server. New-session start and initial Session-load recovery are already handled separately; this closes the remaining in-session reply gap without changing model-picker or route-recovery behavior.

Impact

Users can retry a failed Session reply without re-uploading attachments or risking a duplicate turn, while validation failures keep the existing composer dialog. Targeted client coverage (99 tests), web type checking, lint, formatting, oxlint, and the full pre-push gates pass. The server test suite could not start because this sandbox has no Postgres service at 127.0.0.1:15432 and its Docker daemon is unavailable.

Screenshots

These are representative DOM-rendered simulations captured after authentication was unavailable. They show the intended visual states only; they do not prove the live React, backend, authorization, network, or end-to-end behavior.

[roomote-community]

1 issue outstanding. See task

• apps/web/src/app/(sandbox)/sessions/[sessionId]/SessionPromptInput.tsx:467 Successful retries leave failed-message attachments staged, allowing an unintended duplicate attachment submission.

_{Reviewed 80a9583}

[roomote-community]

A successful retry clears only the draft text. PromptInput keeps its attachment context because this button runs outside its submit lifecycle, so any failed reply with files leaves those files staged after Retry. The now-empty composer still has an enabled submit control, and a later send repeats the attachments as a new message. Clear the attachment context when this retry succeeds (and add coverage for an attachment retry).