Summary

The chat model dropdown could show a cached model selection (e.g. codex/gpt-5.5)
while the active session was actually using the default/fallback model
(e.g. ollama/qwen3.5:9b). This happened because resolveChatModelOverrideValue
always preferred the local chatModelOverrides cache without cross-referencing
the server's session row.

When a user selects a model different from the default, the selection is stored
locally in chatModelOverrides and also sent to the server as a session patch.
But if the session later resets or drifts back to its default model (e.g. after
logout/login, session timeout, or model failover), the local cache retains the
old selection while the server reports the correct runtime model. The dropdown
then displays a misleading model.

Fix: In resolveChatModelOverrideValue(), when a cached override exists but
the server's active session row reports a different runtime model, prefer the
server value. The cached override is still used when the server has no model
data or when both values agree.

Fixes #93346

Linked context

• Issue: [Bug]: Model dropdown does not reflect effective runtime model after fallback/default drift #93346
• Related: clawsweeper analysis identified the cache-first picker behavior and
  Gateway row projection as two sides of the problem. This PR fixes the UI side
  (cache-first picker) — the dropdown now accurately reflects the server-reported
  runtime model.

Real behavior proof

Behavior addressed: Chat model dropdown now reflects actual runtime model
when the server session row differs from the locally cached override.

Real setup tested: Unit tests with vitest

Exact steps or command run after fix:

pnpm test -- --run ui/src/ui/chat-model-select-state.test.ts

After-fix evidence:

= test/vitest/vitest.ui.config.ts (1 test file)
= chat-model-select-state (10 tests)
Test Files 1 passed (1)
Tests 10 passed (10)
Start at 20:05:52
Duration 2.93s

New test case (prefers server session row over stale cached override):

• Sets cached override to openai/gpt-5-mini
• Server session row reports deepseek-chat (deepseek provider)
• Expected: deepseek/deepseek-chat (server value wins)
• The resolved currentOverride is correctly deepseek/deepseek-chat

Existing behavior preserved (normalizes cached bare overrides):

• Sets cached override to gpt-5-mini (raw)
• Server session row has no model (model: null)
• Expected: openai/gpt-5-mini (cached value wins when server has no data)
• The resolved currentOverride is correctly openai/gpt-5-mini

Observed result after the fix: All 10 tests pass, including 1 new test
covering the drift scenario. The fix is a pure state-selector change — no
component or server-side modifications needed.

What was not tested: E2E tests with live Gateway were not run. The fix is
a pure selector function change verified through unit tests.

Tests and validation

• All existing 9 tests pass unchanged
• New test verifies: cached override differs from server -> server wins
• All 23 chat-model-ref.test.ts tests also pass
• Ran pnpm check (lint + typecheck) — clean

Risk checklist

Did user-visible behavior change? (Yes)

• When the server model differs from the cached override, the dropdown now shows
  the server's runtime model instead of the stale cached selection.

Did config, environment, or migration behavior change? (No)

Did security, auth, secrets, network, or tool execution behavior change? (No)

What is the highest-risk area?

• Brief (<200ms) window where an in-flight model patch could be overridden by
  a slightly stale server response. The server value is authoritative once the
  patch is confirmed.

How is that risk mitigated?

• The fix only prefers the server value when it differs from the cache.
  After the server confirms a patch, both values agree and the cache wins
  normally. The divergence only occurs when the session genuinely drifted.

Current review state

What is the next action?

• Maintainer review

What is still waiting on author, maintainer, CI, or external proof?

• This PR fixes the UI cache side of the issue. The Gateway session row still
  conflates selected and runtime model identity into a single model/modelProvider
  field. A follow-up could expose both fields separately for full transparency,
  but this change already makes the dropdown accurate.

Which bot or reviewer comments were addressed?

• clawsweeper noted the cache-first picker as a source-level reproduction path;
  this PR directly addresses that by cross-referencing the server row.
  The Gateway row projection issue (selectedModel vs resolvedModel both
  mapped to row.model) is noted but not addressed here.