feat(vision): image paste + transcript image rendering + vision badge

Vision & vision-handoff frontend (consumes the backend's additive
[email protected] / [email protected] image types — no version bump).

Contracts mirrored:
- .dispatch/wire.reference.md: ImageChunk added to the Chunk union +
  ImageChunk/ImageInput interfaces.
- .dispatch/transport-contract.reference.md: ChatRequest.images,
  ModelMetadata.vision, + ImageChunk/ImageInput re-exports.

Core (core/chunks):
- conformance: assertChunkExhaustive handles the new 'image' variant
  (the guard caught it — its purpose).
- appendUserMessage(state, text, images?) echoes a [text, image, ...]
  user run; the user-message event dedup scans the trailing user run
  (not just the last chunk) so an image-bearing echo doesn't duplicate
  the text; applyHistory's during-gen dedup matches a multi-chunk echo
  by content equality (chunkContentEquals + trailingRun helpers).

UI:
- ChatView renders user 'image' chunks as lazy <img> bubbles; a
  non-vision model's persisted [image, analysis-text] both render.
  read_image tool renders generically (no special-casing).
- Composer: clipboard paste / file picker / drag-drop of images ->
  base64 data URLs, thumbnail previews with remove, forwarded on
  chat.send (omitted when none). Image-only sends allowed; steering
  (chat.queue) never forwards images.
- ModelSelector: vision badge (isVisionModel) marks vision-capable
  models; indicator shows native-vision vs vision-handoff hint.

Store wiring: ChatStore.send + AppStore.send + App.svelte handleSend
thread images through; chat.send still omits cwd (only images added).

Verification: svelte-check 0/0; vitest 901/901 (run twice, +34 new);
biome clean; vite build OK. See backend-handoff.md §2j.

Not merged or pushed.

1 files changed, 3 insertions, 0 deletions

diff --git a/GLOSSARY.md b/GLOSSARY.md
index f0dcdd4..03fd848 100644
--- a/GLOSSARY.md
+++ b/GLOSSARY.md
@@ -26,6 +26,9 @@
 | **steering** | A user message injected into an in-flight turn at the tool-result boundary (drawn from the **message queue**): the model sees it alongside the tool results and may adjust course. Emitted on the chat stream as a `steering` `AgentEvent` (`TurnSteeringEvent`); the queue surface clears on drain (move, don't duplicate). If the turn ends with a non-empty queue (no tool call fired), the queue carries into a NEW turn as its opening prompt (no `steering` event). `[email protected]`. | mid-turn injection, course correction, interruption |
 | **computer** | A remote SSH target discovered from the system's `~/.ssh/config` — a read-only VIEW, NOT an editable entity (no CRUD store; to add one the user edits `~/.ssh/config`). Backend-canonical (`[email protected]`, additive). On the wire as `Computer` (`{ alias, hostName, port, user, identityFile, knownHost }`) + `ComputerEntry extends Computer` (adds `usageCount`, for `GET /computers`). `alias` IS the **computerId** — the string persisted per-conversation / per-workspace (the computer analog of `cwd`). Resolution is SERVER-owned (never re-implement): per-conversation `computerId` → `workspace.defaultComputerId` → `null`/local. USER-facing only: a tool-execution target forwarded to tools, NEVER part of the model prompt (does not affect prompt caching); the agent never sees it. HTTP API (`GET /computers`, `GET`/`PUT /conversations/:id/computer`, `PUT /workspaces/:id/default-computer`, `GET /computers/:alias/status`, `POST /computers/:alias/test`) consumed in handoff #2. | ssh host, remote host, server, connection target |
 | **computerId** | The string id of a **computer** — an SSH config `Host` alias users select. Persisted per-conversation and per-workspace (the computer analog of `cwd`/`workspaceId`). `null` means local (no SSH; today's behavior). On `Workspace` as the REQUIRED `defaultComputerId: string \| null` (null = local / no SSH; the computer analog of `defaultCwd`); per-conversation persistence via `GET`/`PUT`/`DELETE /conversations/:id/computer`. `chat.send` need not send it (resolved server-side from the persisted per-conversation value in the MVP). | ssh alias, host id, remote id |
+| **image chunk** | An `ImageChunk` (`{ type: "image", url, mimeType? }`) — a NEW `Chunk` variant for an image attached to a message (a user-pasted screenshot/photo). `url` is a base64 data URL (`data:image/…;base64,…`) OR an `http(s)://` URL. Backend-canonical (`[email protected]`, additive). A user message may be multi-chunk (`[text, image, image, …]` in order). On the wire as `ImageChunk` (persisted) + `ImageInput` (what `ChatRequest.images` carries; the orchestrator converts each into an `ImageChunk`). | picture, photo attachment, screenshot chunk |
+| **vision** (capability) | Whether a model can natively accept image input (multimodal). On the wire as `ModelMetadata.vision?: boolean` (`GET /models` `modelInfo[name].vision`). `true` (e.g. any `kimi/*` model) → image chunks are passed through to the provider natively. Absent/`false` (e.g. `umans/glm-5.2`) → the server's **vision handoff** transcribes each image to a text description before the model sees it. The FE shows a vision badge in the model picker; it does NOT decide handoff (server-owned). | multimodal, image support |
+| **vision handoff** | The server-owned mechanism by which a NON-vision model still reasons about a pasted image: the orchestrator transcribes the image to a text description (via a vision-capable model) and feeds that text instead, so a text-only model never sees the image directly. The persisted user message keeps the original `image` chunk AND a `text` transcription chunk (`[Image analysis (via <model>)]: …`) in the SAME message — the description is reused on every later turn (no re-transcription). The FE renders both; it sends the image and lets the server decide. Distinct from a vision-capable model, which receives the image natively. | image transcription, vision relay |
 
 ## Frontend-specific
 | Term | Meaning | Aliases to avoid |