fix(ai): default Codex model to gpt-5.3-codex for ChatGPT-account auth

v1.4.13 swung from gpt-5-codex to plain gpt-5, but the chatgpt.com
backend rejects both with the same error:

  {"detail":"The 'gpt-5' model is not supported when using Codex with
  a ChatGPT account."}

The accepted slugs come from the bundled `models.json` in
`codex-rs/models-manager/` — neither `gpt-5` nor `gpt-5-codex` is in
the current bundle. `gpt-5.3-codex` IS in the bundle and is available
on Plus/Pro plans (per `available_in_plans`); verified live against
Marc's account today.

Operators can still override via `CODEX_MODEL` env var if they're on
a different plan tier.

Spec updated with §7a documenting the chatgpt-account-auth allow-list
constraint — the lesson is that the model_migration.rs slug references
are migration *prompts*, not wire slugs. Always cross-check
`models.json`.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs/codex-protocol-spec.md

@@ -613,6 +613,26 @@ The CLI sends the model slug verbatim in the `model` field. There is no enum on
 
 The ChatGPT backend ignores `model` strings the user's account doesn't have entitlements for — the server may safety-route to a different model and report the actual model used in the `OpenAI-Model` response header (§4f). Trust that header, not the request value, when logging.
 
+### 7a. ChatGPT-account-auth allow-list (verified 2026-05-09)
+
+When authenticating via the ChatGPT-OAuth path (Bearer token + `ChatGPT-Account-ID` header, §3a), the backend rejects model slugs that are NOT in the active `codex-rs/models-manager/models.json` bundle. The rejection is HTTP 400 with body:
+
+```json
+{ "detail": "The '<slug>' model is not supported when using Codex with a ChatGPT account." }
+```
+
+Confirmed-rejected slugs (despite the source-tree references in the table above):
+
+- `gpt-5` — rejected
+- `gpt-5-codex` — rejected (the API-key-auth Codex slug; not the ChatGPT-auth one)
+
+Confirmed-accepted slugs on a ChatGPT Plus subscription (per `available_in_plans` in `models.json`):
+
+- `gpt-5.3-codex` — coding-optimized, accepted; HealthLog uses this as default
+- `gpt-5.5` / `gpt-5.4` / `gpt-5.4-mini` / `gpt-5.2` — also expected to work per plan
+
+The `codex-rs/tui/src/model_migration.rs` references to `gpt-5-codex` etc. are *migration prompts* shown to existing users — they are NOT the slugs sent on the wire after migration. The wire slugs come from `models.json`. Always cross-check `models.json` (`gh api repos/openai/codex/contents/codex-rs/models-manager/models.json`) before picking a default.
+
 ---
 
 ## 8. Worked example — minimal end-to-end

src/lib/ai/codex-client.ts

@@ -23,17 +23,28 @@ const CODEX_ENDPOINT = "https://chatgpt.com/backend-api/codex/responses";
 /**
  * Model slug for the ChatGPT-account auth path.
  *
- * Caveat: `gpt-5-codex` is the API-key-auth Codex slug but is rejected
- * by the chatgpt.com backend with "model is not supported when using
- * Codex with a ChatGPT account". For ChatGPT-OAuth we send the plain
- * `gpt-5` slug — that's the Pro/Plus subscription model the backend
- * routes by default. The server may safety-route to a different slug
- * and reports the actual model in the `OpenAI-Model` response header.
+ * The ChatGPT/Codex backend has a tight allow-list of slugs accepted for
+ * subscription auth. As of 2026-05 the bundled Codex models in the
+ * official `openai/codex` client are `gpt-5.5` / `gpt-5.4` /
+ * `gpt-5.4-mini` / `gpt-5.3-codex` / `gpt-5.2`; `gpt-5` and `gpt-5-codex`
+ * are both rejected on this auth path with a 400:
  *
- * Operators can override via `CODEX_MODEL` env var on apps01 if a
- * different slug works better for their ChatGPT plan tier.
+ *   {"detail":"The 'gpt-5' model is not supported when using Codex with
+ *   a ChatGPT account."}
+ *
+ * `gpt-5.3-codex` is the codex-optimized slug available on Plus/Pro
+ * plans (per `codex-rs/models-manager/models.json` `available_in_plans`)
+ * and accepts our HealthLog "summarize health metrics" prompts without
+ * issue (verified live 2026-05-09).
+ *
+ * The server safety-routes when needed and reports the actual routed
+ * model in the `OpenAI-Model` response header — we trust that header
+ * for downstream logging.
+ *
+ * Operators on a different plan can override via the `CODEX_MODEL` env
+ * var on apps01 (e.g. `gpt-5.5` on Free, `gpt-5.4` on Plus/Pro).
  */
-const CODEX_MODEL = process.env.CODEX_MODEL?.trim() || "gpt-5";
+const CODEX_MODEL = process.env.CODEX_MODEL?.trim() || "gpt-5.3-codex";
 
 const ORIGINATOR = "healthlog";
 const USER_AGENT = "HealthLog/1.0 (+https://healthlog.bombeck.io)";