Thread cards: show the model icon (or harness icon + model badge) for multi-model harnesses

[RicardoNid]

Problem

Thread cards (sidebar rows) render only the harness mark. For a multi-model harness such as OpenCode this means every thread shows the identical OpenCode glyph, whether the thread runs deepseek/deepseek-flash, moonshotai-cn/kimi-k3.1-pro, a Qwen model or openai/gpt-5. The icon therefore carries no information about which model a thread is on, and a sidebar with a dozen OpenCode threads is impossible to triage at a glance. The same applies to the compact provider glyph in the thread details header.

Where it comes from (from reading the shipped bundle in 0.1.7)

The card icon is resolved from the provider entry's driverKind — roughly providerEntryByInstanceId.get(thread) → rB({ driverKind }) — and each driver's glyph is hardcoded in the provider registry entry, e.g. kZ({ driverKind: 'opencode', label: 'OpenCode', icon: { ... } }). Model selection never reaches the icon component, and neither customModels ({ slug, name, capabilities }) nor the provider settings schema (binaryPath / serverUrl / serverPassword) has an icon field. There is also no client setting for icon mode today — environmentIdentificationMode controls the Dev/Nightly artwork, not this.

Proposed solution

Either of these, ideally behind a setting:

1. Model-first — when the selected model has a known brand icon, render that instead of the harness glyph, falling back to the harness glyph otherwise.
2. Harness + model — keep the harness glyph and add a small model badge in the bottom-right corner. The composer picker already supports exactly that corner-badge layout (badgeClassName: right-[-0.125rem] bottom-[-0.125rem]), so a 3–4 character model monogram or a brand mark in that slot seems like a small change to an existing component.

A per-thread/per-app display setting — harness only (today's behavior) / model only / both — would keep everyone happy and default to no visual change.

Additional context

• [Feature]: Anthropic/OpenAI icons next to chats to visually sort them #1813 shipped the current behavior for a world where one harness meant one model family. Single harnesses now front many vendors, so the icon needs one more level of detail.
• The ACP registry provider already renders a per-agent icon from acpRegistryIconUrl, which suggests the rendering layer can accept an icon resolved per provider entry — user-defined models would need the same hook (an optional icon on customModels, or an icon URL field).

Environment

T3 Code 0.1.7, Linux desktop, opencode provider driving deepseek/deepseek-flash.