Support durable assistant image attachments in Agent clients

docs/api/streaming-chat.md

@@ -351,6 +351,20 @@ for unloaded-history count semantics and rendering limits.
 
 ### Agent attachment history, queued activity and replay
 
+Assistant image output uses the same `messages` frames and durable history rows,
+with `role: "assistant"`, `id: "outbound:<entryId>"`, `metadata.kind: "message"`,
+`metadata.status: "complete"`, and `metadata.agentAttachments`. Each image descriptor
+contains `id`, `kind: "image"`, `filename`, `mimeType`, `sizeBytes` and `sha256` only;
+there is no source/workspace path or URL. An omitted caption yields empty `content`;
+clients must retain this image-only row. Merge/replay by the unchanged message ID,
+render authenticated image bytes inline in a fixed frame, and retain loaded history
+even if the optional `capabilities.assistantImages.version: 1` is absent later.
+That capability does not authorize input uploads. Native tool image blocks are not
+automatically forwarded; the root agent explicitly calls `output_image`. Public
+output tool rows redact arguments/results, and Agent Markdown does not fetch images.
+See [assistant image output](./rest.md#assistant-image-output-v1) for publishing,
+retry, auth and generic push-preview semantics. No new socket event is introduced.
+
 Uploads and attached sends use REST, as specified in [rest.md](./rest.md#agent-attachments-v1). WebSocket authentication, event types, stable message IDs, cursor semantics and raw tool rows are unchanged. Capability discovery is optional `GET /v1/agent` → `capabilities.attachments.version: 1`; absence disables new attachment sends. Upgrade/authenticate the native runtime and backend before advertising it.
 
 Both `messages.messages[]` and `activity.activity.queuedMessages[]` carry attachment descriptors under **`metadata.agentAttachments`**, distinct from ordinary chat's inline `metadata.attachments`: