per-session models: every session owns its model + thinking level from birth

The reported bug (2026-09-28): every chat ran glm-5.3-flash regardless of
any pick, while composer and settings UIs agreed with each other and lied
about the run. Root cause: a fossil default-settings record (settings.json
chat section, frozen pre-slots-wave) was stamped verbatim into every new
chat at birth by the new-session flow, and resolveConversationSpec prefers
the per-chat record over the strong slot forever.

Owner redesign — models are per session, always; the strong slot is the
new-session default:

- POST /api/chats stamps the newborn verbatim from the strong slot
  (model + thinking level); no client settings PUT on create anymore
- the composer control is dual-bound: in-session it reads/writes the
  session's own record (GET /api/chats/:id, PUT .../settings); on the
  draft surfaces it binds the strong slot (picking there = changing the
  default)
- thinking levels follow the identical mechanics (confirmed by owner)
- the zombie default-settings system dies whole: useDefaultSettings,
  /api/settings/defaults, src/store/default-settings.ts, the chat
  section of UserSettings (sanitizer strips fossil copies), the legacy
  default-settings.json fold, and DEFAULT_SETTINGS_FILE
- catalogDefaultsFor collapses to the strong slot alone
- thinking display for a legacy unstamped session resolves exactly like
  the engine (session ?? strong ?? model ladder)

Tests: new chat-birth-stamp suite pins the stamp, the unconfigured boot,
the unset level, and the copy-not-live-view regression; defaults pins
rewritten strong-only; legacy-migration suite deleted.

app/page.tsx

@@ -1,11 +1,10 @@
 import { Home } from "@/components/home";
-import { readDefaultSettings, readSettingsRecord } from "@/src/server";
+import { readSettingsRecord } from "@/src/server";
 import { slotsConfigured } from "@/src/core";
 
-// Dynamic: the default settings record is server-rendered into the page —
-// the model + thinking + context controls show truth on the FIRST frame
-// (no default-model flash), and every navigation re-reads the record
-// (dynamic routes aren't cached client-side).
+// Dynamic: the configured state is server-rendered into the page (the
+// setup CTA's truth on the first frame), and every navigation re-reads
+// the record (dynamic routes aren't cached client-side).
 export const dynamic = "force-dynamic";
 
 export default function HomePage() {
@@ -14,6 +13,6 @@ export default function HomePage() {
 	// record's models section lacks any slot pin.
 	const record = readSettingsRecord();
 	return (
-		<Home initialSettings={readDefaultSettings()} initialConfigured={slotsConfigured(record?.models)} />
+		<Home initialConfigured={slotsConfigured(record?.models)} />
 	);
 }