[chuks-qua]

What

Before: Fast was a Codex-only setting named codexFastMode, and the Codex adapter read the global provider.codex.fastMode default itself.

Now: Fast is a provider-neutral fastMode on the wire, in the web stores, and on the thread row (fast_mode). Turn admission resolves it and sends it only to models whose catalog entry declares supportsFastMode:

 buildTurnRequest
-  providerOptions.fastMode = command ?? thread.codex_fast_mode   (Codex only)
-  codex adapter: fastMode ?? settings.provider.codex.fastMode
+  fastMode = command ?? thread.fast_mode ?? (Codex ? settings default : undefined)
+  if fastMode and catalog[model].supportsFastMode
+    providerOptions.fastMode = true
+  codex adapter: fastMode === true -> serviceTier "priority"

Forks inherit the parent's fast_mode. A provider switch drops Fast unless the target model declares it.

Verified with targeted Vitest runs:

Check	Result
Codex Fast still sends serviceTier: "priority" (codex-provider-first-turn)	pass
Fork inherits Fast on the thread row and first turn (thread-creation-startup)	pass
Migrated DB keeps every thread's Fast value; older-build writes stay in sync (database-migration-success)	pass
Non-declaring model, other provider, and failed catalog read get no fastMode (turn-admission-fast-mode)	pass
Server tests touching Fast	17 files, 318 passed
Web tests touching Fast	18 files, 436 passed
bun run typecheck, bun run lint	pass

Out of scope: the Claude adapter, a Claude default, and lifting the web composer's provider === "codex" gates belong to MPE-03 (#2229).

Why

MPE-03 needs Fast for Claude models. Keying Fast on model capability instead of the provider name lets any adapter opt in by declaring supportsFastMode. A model that can't take Fast never receives it.

Closes #2227.

Review Notes

Database migration 0098 (compatible step). It adds nullable threads.fast_mode, backfills it from codex_fast_mode, and adds two triggers. Stable and nightly share ~/.mcode/mcode.db, so:

• New builds write both columns on every settings update.
• Older builds write only codex_fast_mode. The triggers copy those writes into fast_mode.
• The insert trigger fires only when fast_mode is null, so a newer build's insert keeps its value.
• Drop both triggers before dropping codex_fast_mode once the compatibility floor passes 0098.

Other legacy keys. Queued automatic-setup submissions are parsed strictly by older builds, so submission_json keeps storing Fast under codexFastMode and accepts either key on read. Saved composer drafts with the old key keep their value.

Catalog failure. If the model catalog can't be read, admission logs a warning and sends the turn at standard speed instead of failing it. A Codex user with Fast on would get a standard-tier turn during a catalog outage.

Global default. provider.codex.fastMode is unchanged and still applies only to Codex threads.

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}