a session remembers which model it is using

resume a conversation and the model picker showed the first entry in the catalogue instead of the model the
session was actually on. that was invisible for as long as the first entry was `opus`, and became obvious
the day `fable` went above it — so this is a pre-existing bug my model-list change exposed, not one it
introduced.

two defects, stacked.

the value did not survive a refresh: `initialModel` came from `props.model ?? locationState?.model`, and
both are volatile — a panel channel and react-router location state. on a hard load neither exists, the
settings default is skipped (it only runs for NEW chats), and ModelSelector's fallback effect fired
`onModelChange(providerModels[0].id)`.

and even when it did arrive it could not match. a transcript records the API model; the picker offers CLI
aliases. `claude-opus-5` is in a different id space from `claude-code/opus[1m]`, and the mapping is one-way:
opus and opus[1m] both serve claude-opus-5, opusplan serves whichever model answered. read out of a real
59MB transcript, the distinct values were claude-opus-5, <synthetic>, claude-sonnet-5,
claude-haiku-4-5-20251001, claude-fable-5 — note the synthetic marker and the inconsistent date suffix.

so the transcript cannot answer "what should the picker show", and a new table does:

  chat_session_models (session_id pk, model, updated_at)

officer's own id space, so opus[1m] and opusplan round-trip. keyed on the TRANSCRIPT uuid rather than
officer's session id, because that is what the session list joins on — which is why the write waits for the
harness to announce the id rather than firing at turn start. records the EFFECTIVE model, so a refused
switch stores what answered.

not derived from chat_session_events, which does now hold model:switched: right data, wrong index. that
table holds every assistant message and is unbounded, and "latest model for these 200 sessions" would scan
far more than the question deserves. not a chat_sessions table either — a session IS its transcript, and a
row holding title and cwd would be a second source of truth for two fields that already have one.

BACKFILL RUNS FROM postdb:push, so every server picks it up on its next schema push. bun does fire pre/post
hooks for colon-named scripts — verified on 1.3.14 before building on it, because a post hook that silently
never runs is the worst outcome here. insert-only, exits 0 on every failure path (the push has already
applied; a cosmetic backfill must not make it look failed). seeded 11 of 12 transcripts on this machine.

it reads the FIRST model, which sounds wrong for a table storing the current one — but switching only
became possible today, so no older transcript can hold two, and first costs a bounded head read instead of
reading 59MB.

also: the family map returns null for mythos rather than a neighbouring family (Project Glasswing only — a
picker entry that 401s is worse than none), and ModelSelector no longer picks a default once a conversation
has started. an unset picker is the honest state when the server cannot say.

tests: the alias map against the five real transcript values, and the selector's default gated on
hasStarted. re-broke the guard to confirm it bites.

still to do: `model` on the session LIST rows, which the sessions-list revamp wants. the storage and the
batched read (getChatSessionModels) are in place for it.

src/servers/api/chat/chat.ts

@@ -4,7 +4,7 @@ import { pauseBackgroundTask, restartBackgroundTask } from './task-restart';
 import { createRouter } from '../../create-router';
 import * as errors from '@@/custom-errors';
 import * as sidecar from '@@/sidecar-registry';
-import { getUserSettings } from 'officerdb';
+import { getUserSettings, getChatSessionModel } from 'officerdb';
 import {
   listClaudePwds,
   listClaudeSessions,
@@ -29,6 +29,7 @@ import { listChatModels } from './list-models';
 import { logger } from './logger';
 import { resolveHomeDir } from '@@/user-home';
 import type { ChatIdentity } from './claude-sessions';
+import { officerModelForApiModel } from './model-aliases';
 import { readSttConfig } from '../server-settings/stt';
 
 /**
@@ -150,8 +151,27 @@ chatRouter.get('/sessions/:id', async (ctx) => {
   // own, so it gets neither rather than a fabricated answer.
   const context = isOpenCodeSessionId(id) ? null : claudeSessionContext(who, detail.cwd, id);
 
+  /*
+    The model the PICKER should show, which is not the model `detail` reports.
+
+    `detail.model` is scraped out of the transcript, so it is an API id (`claude-opus-5`) — a different id
+    space from what the picker offers (`claude-code/opus[1m]`), and lossy: `opus` and `opus[1m]` both write
+    `claude-opus-5`, and `opusplan` writes whichever model answered. Handing that to the client resolved to
+    nothing in the catalogue, the picker fell back to the first entry, and a resumed conversation came back
+    showing the wrong model.
+
+    So the stored row wins where there is one, and the family guess is the fallback for sessions that have
+    not taken a turn since `chat_session_models` landed. Null when neither can answer — the client shows no
+    model rather than guessing, which is the whole defect being fixed.
+  */
+  const officerModel =
+    (await getChatSessionModel(id).catch(() => null)) ?? officerModelForApiModel(detail.model) ?? null;
+
   return ctx.json({
     ...detail,
+    // `detail.model` stays on the payload untouched — it is the honest record of what the API served, and
+    // the detail view may want it. `officerModel` is the separate question of what to select in the picker.
+    officerModel,
     messages,
     total,
     offset: windowed ? start : 0,