show the model that answered instead of the bare harness string

the picker rendered the literal `claude-code` for any chat that named no
tier. that is DEFAULT_MODEL — the bare harness — and it routes correctly
(no --model is passed, so the cli picks for itself) but names no catalogue
entry, so radix matched no item and the fallback from 773f0e1c printed the
raw string's last segment.

officer cannot answer this because it deliberately did not choose. the
harness does, in its system.init `model` field, which the parser was
discarding. so: emit it as a `model:resolved` chat event, translate it to an
officer id in turn-stream, and forward it to the client only when the turn
named no tier.

that last condition is the load-bearing one. the alias map is lossy in one
direction — opus[1m] and opusplan both answer as claude-opus-5 — so
forwarding unconditionally would silently relabel a user's own choice as
plain opus.

display only, and three ways: not durable (like session:claude), never
recorded to chat_session_models, and never written into the client's
selectedModel or the reattach ref. storing it would pin a session to
whatever the cli defaulted to on its first turn, which is the freedom the
bare harness exists to preserve.

untested against a live turn — the parser and translator have unit tests,
the websocket gate does not.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/servers/api/chat/types.ts

@@ -282,6 +282,27 @@ export type ServerMessage =
     answered, as `from` — so it says what actually happened rather than what was asked for.
   */
   | { type: 'model:switched'; from: string | null; to: string; ok: boolean; error?: string }
+  /*
+    What the harness says it is actually running, as opposed to what the turn asked for.
+
+    Officer's `DEFAULT_MODEL` is the BARE HARNESS, `claude-code` — sent when the client names no model and
+    the account has no default. It routes correctly (no `--model` is passed, so the CLI picks for itself)
+    and it names no catalogue entry, so the picker had nothing to render and showed the literal string
+    `claude-code`. The server could not do better because it deliberately did not choose: only the harness
+    knows, and it says so in its `system.init`.
+
+    So this is DISPLAY ONLY, and three things follow from that:
+
+      - It is live-only, like `session:claude`. A replayed log gets the model from `session:init` and from
+        `GET /chat/sessions/:id`, which reads the transcript.
+      - It is sent only when the requested model does NOT name a tier. The alias map is lossy — `opus[1m]`
+        and `opusplan` both resolve back to plain `opus` — so a user who picked either must not watch their
+        choice silently flatten.
+      - It is never stored and never becomes the client's `selectedModel`. Storing it would pin a session to
+        whatever the CLI happened to default to on its first turn, which is exactly the freedom the bare
+        harness exists to preserve.
+  */
+  | { type: 'model:resolved'; model: string }
   /*
     Plan mode, in three messages.
 
@@ -322,6 +343,7 @@ export type TurnMessageType =
   | 'compact:start'
   | 'compact:done'
   | 'model:switched'
+  | 'model:resolved'
   | 'plan:mode'
   | 'plan:proposed'
   | 'plan:decided';
@@ -361,6 +383,9 @@ export type ChatEvent =
   | { type: 'compact:done'; trigger: 'manual' | 'auto'; preTokens: number; durationMs?: number }
   // Emitted by `applyModelChange` when a live session moves onto a different tier — see claude-manager.
   | { type: 'model:switched'; from: string | null; to: string; ok: boolean; error?: string }
+  // The harness's own `system.init` model, as an ANTHROPIC api id (`claude-opus-5`). Translated to an
+  // Officer id in `turn-stream`, because everything downstream of the sidecar speaks Officer ids.
+  | { type: 'model:resolved'; apiModel: string }
   // Plan mode — see the matching ServerMessage members for what each one means.
   | { type: 'plan:mode'; enabled: boolean; ok: boolean; error?: string }
   | { type: 'plan:proposed'; requestId: string; plan: string }

src/servers/api/chat/websocket.ts

@@ -415,6 +415,28 @@ function createMessageHandler(sessionId: string, model: string, resumeSessionId?
       record();
     }
 
+    /*
+      What the harness reports it is running — forwarded ONLY when the turn did not name a tier.
+
+      `effective` without a `/` is the bare harness, `claude-code`: the client chose nothing, officer passed
+      no `--model`, and the CLI picked. That is the only case where the harness knows something officer does
+      not, and it is the only case where this may speak.
+
+      When the turn DID name a tier, this is dropped on the floor, because the translation back from an API
+      id is lossy in exactly the directions that matter: `claude-code/opus[1m]` and `claude-code/opusplan`
+      both answer as `claude-opus-5`, so forwarding would quietly relabel the user's own choice as plain
+      opus. `model:switched` already covers a real change.
+
+      Not recorded, not folded, not `sessionManager.setModel`. `session.model` is what dispatch and the stop
+      path route on, and it is correct as the bare harness; and `record()` refuses a model without a `/` for
+      a reason worth reading before changing any of this.
+    */
+    if (msg.type === 'model:resolved') {
+      if (effective.includes('/')) return;
+      for (const socket of session.sockets) sendToClient(socket as ServerWebSocket<WSData>, msg, seq);
+      return;
+    }
+
     // Follow the harness, never the request — a refused switch (`ok: false`) leaves the session where it was,
     // and recording the attempt would restore a mode the agent is not in.
     if (msg.type === 'plan:mode' && msg.ok) {