fix(custom-model): pre-approve the injected API key in the isolated Claude config dir

The CLAUDE_CONFIG_DIR isolation from the previous commit fixed the cosmetic
auth warning but introduced a real regression: an otherwise-empty config
directory has none of a real profile's prior custom-API-key approvals, so
Claude Code stops at an interactive 'Detected a custom API key - use it?'
prompt on every single launch. Confirmed live. With nobody at a TTY to
answer, the prompt's own default ('No') silently refuses the very key this
feature just injected, which looks like the endpoint being ignored.

Adds apiKeyTrustFile to the env-kind customModelInjection capability shape
({relPath, shape: 'claude-api-key-responses'}), set on claude's entry to
{relPath: '.claude.json', shape: 'claude-api-key-responses'}. The apply step
merges customApiKeyResponses.approved: [apiKey] into
<isolatedConfigDir>/.claude.json - the exact field a real answered prompt
itself writes to (confirmed against a real ~/.claude.json after answering by
hand once), so this answers the prompt in advance rather than bypassing it.
Merges onto whatever the CLI already wrote into that file on an earlier
launch in the same isolated directory rather than overwriting it; a missing
or corrupt file is treated as empty rather than failing the apply.

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

docs/custom-model-endpoints.md

@@ -188,6 +188,24 @@ registry entry (`contextLengthVar`/`configDirVar`), not hardcoded here:**
   the pre-existing blind-response-viewer side effect rather than failing the
   whole custom-model apply over it.
 
+**That isolated directory needed one more fix to actually be usable
+non-interactively.** An otherwise-empty `CLAUDE_CONFIG_DIR` has none of a
+real profile's prior "Detected a custom API key — use it?" approvals, so
+without more, Claude Code stops and asks that on *every single launch* —
+confirmed live, and with nobody at a TTY to answer, its own default answer
+("No") silently refuses the very key this feature just injected, which
+looks like the endpoint being ignored entirely. `customModelInjection`'s
+`apiKeyTrustFile` (`{ relPath: '.claude.json', shape:
+'claude-api-key-responses' }` on claude's entry) pre-seeds that exact
+approval: the apply step merges `customApiKeyResponses.approved: [apiKey]`
+into `<configDir>/.claude.json`, the same field a real answered prompt
+itself writes to (confirmed against a real file after answering by hand
+once) — this answers the prompt in advance rather than bypassing it. The
+merge preserves whatever else the CLI already wrote into that file on an
+earlier launch in the same isolated directory (`userID`, `numStartups`,
+earlier approved keys), and a missing or corrupt file is treated as empty
+rather than failing the apply.
+
 Clear back to the harness's native cloud default with:
 
 ```bash

docs/wiki/Custom-Model-Endpoints.md

@@ -80,7 +80,10 @@ currently offer these entries.
   requests (the API key wins) but the CLI still prints a "both claude.ai and
   ANTHROPIC_API_KEY set" warning about it, which this avoids entirely. The isolated directory
   keeps a link back to your real session history so the response viewer and similar features
-  still work for that session.
+  still work for that session. That isolated directory starts with no prior approvals of its
+  own, so Codeman also pre-approves the injected key the same way answering Claude Code's own
+  "Detected a custom API key" prompt once would — without it, that prompt would otherwise
+  reappear on every single launch with nobody there to answer it.
 
 ## Which harnesses actually work