backend, web: support for resuming streams

docs/api/rest.md

@@ -39,6 +39,22 @@ Chat upload limits:
 ```
 - OpenAI model lists are filtered to models that are expected to work with the backend's Responses API implementation.
 
+## Active Runs
+
+### `GET /v1/active-runs`
+- Response:
+```json
+{
+  "chats": ["chat-id-with-active-stream"],
+  "searches": ["search-id-with-active-stream"]
+}
+```
+
+Behavior notes:
+- Lists in-memory chat/search streams that are still running on this server process.
+- Clients should use this after app start or page refresh to restore per-row generating indicators.
+- The lists are not durable across server restarts.
+
 ## Chats
 
 ### `GET /v1/chats`
@@ -260,6 +276,32 @@ Search run notes:
 - Persists answer text/citations + ranked results.
 - If both search and answer fail, endpoint returns an error.
 
+### `POST /v1/searches/:searchId/run/stream`
+- Body: same as `POST /v1/searches/:searchId/run`
+- Response: `text/event-stream`
+
+Events:
+- `search_results`: `{ "requestId": string|null, "results": SearchResultItem[] }`
+- `search_error`: `{ "error": string }`
+- `answer`: `{ "answerText": string|null, "answerRequestId": string|null, "answerCitations": SearchDetail["answerCitations"] }`
+- `answer_error`: `{ "error": string }`
+- terminal `done`: `{ "search": SearchDetail }`
+- terminal `error`: `{ "message": string }`
+
+Behavior notes:
+- The stream is owned by the backend after it starts. If the original HTTP client disconnects, the backend keeps running and persists the final search state.
+- While a search stream is active, `GET /v1/active-runs` includes the `searchId`.
+- If a stream is already active for the same `searchId`, this endpoint attaches to the existing stream instead of starting a second run.
+
+### `POST /v1/searches/:searchId/run/stream/attach`
+- Body: none
+- Response: `text/event-stream` with the same event names as `POST /v1/searches/:searchId/run/stream`
+- Not found: `404 { "message": "active search stream not found" }`
+
+Behavior notes:
+- Replays buffered events for the active in-memory stream, then emits new events until `done` or `error`.
+- Intended for clients that discovered a pending search via `GET /v1/active-runs`, such as after browser refresh.
+
 ## Type Shapes
 
 `ChatSummary`

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: