backend, web: support for resuming streams

docs/api/streaming-chat.md

@@ -4,6 +4,7 @@ This document defines the server-sent events (SSE) contract for chat completions
 
 Endpoint:
 - `POST /v1/chat-completions/stream`
+- `POST /v1/chats/:chatId/stream/attach`
 
 Transport:
 - HTTP response uses `Content-Type: text/event-stream; charset=utf-8`
@@ -61,6 +62,23 @@ Notes:
 - For persisted streams, backend stores only new non-assistant input history rows to avoid duplicates.
 - Attachments are optional and are persisted under `message.metadata.attachments` on stored user messages when `persist` is `true`.
 
+Persisted chat streams with a `chatId` are backend-owned active runs:
+- Once started, the backend keeps the stream running even if the HTTP client disconnects or refreshes.
+- While running, `GET /v1/active-runs` includes the `chatId`.
+- Starting a second persisted stream for the same active `chatId` returns `409`.
+- Clients can reattach with `POST /v1/chats/:chatId/stream/attach`.
+
+## Attach Endpoint
+
+`POST /v1/chats/:chatId/stream/attach`
+- Body: none.
+- Response uses the same `text/event-stream` transport and event names as `POST /v1/chat-completions/stream`.
+- Replays buffered events for the active in-memory stream, then emits new events until `done` or `error`.
+- Returns `404 { "message": "active chat stream not found" }` if no stream is currently active for that chat.
+- Authentication is the same as all other API endpoints.
+
+This endpoint is intended for clients that restored an active `chatId` from `GET /v1/active-runs`, especially after browser refresh. Replayed `delta` events may include text that was originally emitted before the client attached.
+
 ## Event Stream Contract
 
 Event order: