Bug: composer eats typed text on 4xx/5xx send failure

[heavygee]

Problem

When the message composer submits and the hub responds with a 4xx or 5xx (or the fetch fails outright), the composer clears the input -- the operator's typed text is destroyed. This is destructive at exactly the moment the operator most needs their text retained so they can retry without losing what they wrote.

Example: composer fires POST /api/sessions/:id/messages, hub returns 503 during a restart -> text discarded.

This is reproducible during any hub restart blip. @assistant-ui/react's composer clears composer.text synchronously the moment send is invoked, so by the time useSendMessage's mutation rejects the input is already gone.

Proposal

Don't clear the composer on error. Only clear on 2xx.

1. On 2xx - clear input, finalise the optimistic render (today's behaviour).
2. On 4xx / 5xx / network error - restore the input (don't destroy it), surface the error inline, allow retry.
3. The operator can edit the retained text and retry without retyping.

Acceptance

• Submit -> 500/502/503/network error -> composer text not cleared
• Submit -> 400/401/403 -> composer text not cleared, error surfaces inline
• Submit -> 2xx -> composer clears as today
• Operator can edit retained text and retry without re-typing
• Test covering all three branches

Notes

• Composer wiring lives in web/src/components/AssistantChat/HappyComposer.tsx and web/src/hooks/mutations/useSendMessage.ts.
• A small visual on the composer (red ring + inline error message) is welcome alongside text retention so the failure is obvious.

[github-actions]

Confirmed from the current web send path. The request failure is observable by the app, but the composer does not currently wait for that result or restore text after a failed POST.

What I verified:

• POST /api/sessions/:id/messages returns 400 for invalid body / empty message and otherwise returns { ok: true } after engine.sendMessage(...) completes.
• The web API client throws for any non-OK HTTP response, including 4xx / 5xx from that POST.
• useSendMessage catches that through the React Query mutation and marks the optimistic message as failed, but sendMessage() currently starts mutation.mutate(...) and returns true before the async POST has succeeded or failed.
• The assistant runtime adapter calls props.onSendMessage(...) without awaiting/returning the result, so the composer layer is not currently tied to POST success vs failure.

So the reported behavior matches the current implementation surface: failure state exists for the optimistic message, but not for retaining/restoring the composer text or showing an inline composer error.

Relevant code:

• web/src/components/AssistantChat/HappyComposer.tsx:341 - Enter key invokes api.composer().send().
• web/src/components/AssistantChat/HappyComposer.tsx:529 - send button also invokes api.composer().send().
• web/src/lib/assistant-runtime.ts:627 - runtime onNew extracts composer text/attachments.
• web/src/lib/assistant-runtime.ts:635 - runtime calls props.onSendMessage(...) without awaiting/returning the send result.
• web/src/components/SessionChat.tsx:517 - session send handler awaits props.onSend(...), but only receives the hook's early accepted/blocked boolean.
• web/src/hooks/mutations/useSendMessage.ts:93 - mutation performs api.sendMessage(...).
• web/src/hooks/mutations/useSendMessage.ts:114 - failed mutation marks the optimistic message failed.
• web/src/hooks/mutations/useSendMessage.ts:156 - sendMessage() starts mutation.mutate(...).
• web/src/hooks/mutations/useSendMessage.ts:164 - sendMessage() returns true immediately after mutation start, before POST success/failure.
• web/src/api/client.ts:125 - API client throws on non-OK HTTP responses.
• web/src/api/client.ts:325 - web client sends POST /api/sessions/:id/messages.
• hub/src/web/routes/messages.ts:63 - route parses request JSON.
• hub/src/web/routes/messages.ts:65 - invalid request body returns 400.
• hub/src/web/routes/messages.ts:74 - route calls engine.sendMessage(...).
• hub/src/web/routes/messages.ts:81 - successful route response is { ok: true }.

Need more info:

• Browser + device where you reproduced this, if there is a platform-specific keyboard path involved.

---

HAPI Bot

[heavygee]

PR up: #773