docs(custom-model): record live findings on codex's model-metadata warning

Investigated the user's report of "Model metadata for <id> not found.
Defaulting to fallback metadata..." on every custom-endpoint codex
launch, live against the test-picker's llama-swap deployment (codex
0.152.1):

- The warning is cosmetic. `codex exec 'reply with just OK'` against the
  isolated CODEX_HOME still printed the warning and still returned a
  real reply.
- The isolated CODEX_HOME never gets a models_cache.json written into
  it at all, even after extended real use (inspected a live, actively-
  used directory) — codex can't reach OpenAI's own hosted model catalog
  for this session and silently falls back every time, with no local
  file to create or clean up. There is also no config.toml override for
  a model's metadata.
- Fabricating a fake catalog entry to suppress it would mean copying the
  SHAPE of OpenAI's own proprietary models_cache.json schema, including
  real per-model system-prompt content visible in a genuine entry — not
  something to build for a warning confirmed to have no effect.
- More importantly: a real tool-call attempt against the same setup came
  back as agent_message TEXT (the tool-call JSON printed as the answer)
  rather than an executable function_call item, confirmed via
  `codex exec --json`'s raw event stream. Tool execution is what makes
  codex a coding agent, so it remains not usable for real work regardless
  of the metadata warning — a more precise, re-verified update to the
  existing "Responses API protocol gap" finding (which reported a harder
  Reconnecting/high-demand failure on a different llama-swap deployment;
  this one answers /v1/responses for plain chat but still can't execute
  tools).

No code changes — recipe/comment/confidence-table documentation only.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RqZeHrRS6DYcGcGX2p9EwG

src/custom-model-injection.ts

@@ -16,14 +16,21 @@
  * shape was rejected by a real codex binary with "invalid type: map,
  * expected a string" — caught by `scripts/test-local-llm-harnesses.ts`),
  * but `wire_api = "responses"` is the only value codex still accepts
- * (support for `"chat"` was dropped in Feb 2026), and a plain OpenAI
- * Chat-Completions server (llama.cpp, llama-swap, most local setups) does
- * NOT implement the Responses API — so codex may still fail at the
- * PROTOCOL level even with a correctly-shaped config file. That gap is
- * real and current, not a stale warning; see docs/custom-model-endpoints-plan.md. The rest
- * (gemini/pi/grok/deepseek/omp) have their ONE-SHOT INVOCATION flags
- * confirmed against real installed binaries' own `--help` output, but
- * their custom-endpoint env/config conventions remain web-researched,
+ * (support for `"chat"` was dropped in Feb 2026). ⚠️ Re-verified live
+ * against a llama-swap deployment that DOES answer `/v1/responses`: a
+ * plain, no-tool-call turn gets a real reply, but a real tool-call attempt
+ * comes back as `agent_message` TEXT (the tool-call JSON printed as the
+ * answer) rather than a `function_call` item codex would execute —
+ * confirmed via `codex exec --json`'s raw event stream. Tool execution is
+ * what makes codex a coding agent, so this remains not usable for real
+ * work even where plain chat succeeds; see docs/custom-model-endpoints-plan.md
+ * for the full picture (including the harmless `Model metadata ... not
+ * found` warning every custom-endpoint codex session prints — sourced from
+ * a local cache of OpenAI's OWN hosted model catalog that a custom model
+ * can never appear in, confirmed to have no effect on the outcome above).
+ * The rest (gemini/pi/grok/deepseek/omp) have their ONE-SHOT INVOCATION
+ * flags confirmed against real installed binaries' own `--help` output,
+ * but their custom-endpoint env/config conventions remain web-researched,
  * unverified.
  */
 
@@ -200,11 +207,13 @@ function renderConfigFile(
       // `env_key`, the NAME of an env var it reads the credential from at runtime, so the
       // actual value must ride along as an extra env var, never embedded in the file.
       // ⚠️ `wire_api = "responses"` is the only value codex still accepts (it dropped
-      // `"chat"` support in Feb 2026) — a plain OpenAI Chat-Completions server (llama.cpp,
-      // llama-swap, most local setups) does NOT implement the Responses API, so this
-      // recipe may still fail at the PROTOCOL level even though the file now parses
-      // correctly. That is a real, currently-unresolved compatibility gap, not a syntax
-      // bug — track it before calling codex support done.
+      // `"chat"` support in Feb 2026). Even against a llama-swap deployment that DOES
+      // answer `/v1/responses`, a real tool-call attempt came back as plain TEXT (the
+      // tool-call JSON printed as the model's answer) rather than an executable
+      // `function_call` item — confirmed live via `codex exec --json`. Tool execution is
+      // what makes codex a coding agent, so this remains not usable for real work even
+      // where plain chat succeeds — see the confidence table in
+      // docs/custom-model-endpoints-plan.md, not a syntax bug in this file.
       const content = [
         `model = ${quoted(modelId)}`,
         `model_provider = "custom"`,