fix(custom-model): unset injected env on clear, resume on restart, select the model for pi/omp/grok

Custom Model Endpoint Profiles (#393) let a session point its CLI at a
custom OpenAI-compatible endpoint by injecting env vars or a config file
and restarting the CLI in place. Review of the apply path found four
things, two of them destructive. This lands all four plus the smaller
items from the same review.

1. Clearing a selection did not clear it. The injected vars reach the CLI
   via `tmux setenv`, which persists at the tmux-session level and is
   inherited by `respawn-pane` (measured: `setenv FOO bar` survived two
   successive `respawn-pane -k`), so deleting the keys from the session's
   envOverrides relaunched the CLI still pointed at the old endpoint, and
   for the configDir kinds at a HOME/CODEX_HOME/GROK_HOME that had just
   been deleted. `Session.setCustomModel()` now reports the removed keys,
   queues them (`_pendingEnvUnsets`), and `RespawnPaneOptions.unsetEnvKeys`
   carries them into `applyEnvOverrides()`, which `setenv -u`s them before
   re-applying the live overrides, on the same path that already unsets
   the legacy CLAUDE_CODE_EFFORT_LEVEL. Verified on a private tmux socket
   that `setenv -u HOME` hands the next respawn the global HOME back.

2. Applying a model to a local claude session killed the pane. The
   relaunch was `claude --session-id <id>` and Claude refuses an id that
   already has a transcript, and unlike the dead-pane respawn this one
   kills a working pane first. `restartCli()` now pins the live
   conversation id as the resume id for that respawn when the CLI's launch
   declares a `fallback` chain, which renders the same
   `--resume <id> || --session-id <id>` shape the docker and remote pane
   commands use. Gated on the registry shape, not the CLI id: an entry
   whose resume id is minted by the CLI itself never declares that chain.

3. pi, omp and grok wrote their config file and then launched without the
   `--model` that selects it, so the file was ignored. The registry entry
   now declares `customModelInjection.launchModel` (`custom/{modelId}` for
   pi and omp, grok's `[model.codeman-custom]` block name), the builder
   renders it, and `_withCustomModelLaunchModel()` applies it onto the
   respawn options through `legacyConfigField`, leaving the stored
   <Mode>Config untouched so a clear falls back to the user's own model.
   A model id the CLI's `model` token pattern cannot carry is refused
   with a 400 rather than silently dropped by the argv engine.

4. Remote (SSH) and Docker sessions reported `restarted: true` and changed
   nothing: their `restartCli()` reattaches the durable tmux rather than
   relaunching the agent, and the env lands on the local pane. Both are
   refused with a 400 until those paths are plumbed.

Smaller items from the same review:

- The selection survives a Codeman restart as the disk-only `__customModel`
  bookkeeping (endpoint, model, injected key NAMES, config dir, launch
  model; never the values, which carry the API key). Recovery re-derives
  the values from the endpoint store through the same apply path the route
  uses and keeps the bookkeeping even when the endpoint is gone, so a
  later clear still has keys to unset.
- Discovery goes through `webviewFetch()`, so the RESOLVED address is
  judged by the same egress guard the web-tab proxy uses, and `baseUrl`
  reuses `webviewUrlSchema` (http(s) only, no embedded credentials,
  link-local and cloud-metadata addresses refused). undici's `fetch failed`
  wrapper is unwrapped so the user sees the ECONNREFUSED underneath.
- `custom-model-hosts.json` is written 0600 via tmp+rename, the per-session
  config dir 0700/0600 (pi and omp embed the key literally), and that dir
  is removed with the session.
- `PR.md` is gone from the repo root and the design doc moved to
  `docs/custom-model-endpoints-plan.md` with the LAN address and the
  personal name scrubbed; every reference follows. The guide's `authStyle`
  text matches the shipped schema (`bearer | api-key`, default `bearer`)
  and says that `customModelEndpointsEnabled` is read by nothing until
  the picker lands.
- `config/tsconfig.scripts.json` typechecks `scripts/test-local-llm-harnesses.ts`
  (four real type errors fixed). It is not yet wired into `npm run typecheck`
  because that line differs on master; adding `&& tsc -p config/tsconfig.scripts.json`
  there is the one-line follow-up.

Tests: `test/session-custom-model-restart.test.ts` drives a real Session and
fails on the unfixed code for items 1 to 3; the route suite covers item 4
and the pattern refusal; `test/tmux-manager.test.ts` pins that the unsets
run before the overrides and that a shell-metachar key never reaches tmux.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

docs/custom-model-endpoints.md

@@ -9,7 +9,7 @@ services (Azure AI Foundry's OpenAI-compatible endpoint, OpenRouter, a
 company gateway) — anything answering `GET /v1/models` and
 `POST /v1/chat/completions` in the standard shape. Design doc, per-CLI
 recipe confidence table, and security reasoning:
-[`deployment_plan.md`](../deployment_plan.md).
+[`custom-model-endpoints-plan.md`](custom-model-endpoints-plan.md).
 
 > **Status**: backend is implemented and tested (registry capability, the
 > injection engine, the endpoint store + discovery route, the session
@@ -21,7 +21,10 @@ recipe confidence table, and security reasoning:
 ## Turning it on
 
 App Settings → Agents & CLIs → **Custom Model Endpoints** (synced setting
-`customModelEndpointsEnabled`, default **OFF**). The API equivalent:
+`customModelEndpointsEnabled`, default **OFF**). Until the toolbar picker
+lands, nothing reads this setting: the HTTP routes below work whether it is
+on or off, and it exists now only so the picker has a switch to hang off
+when it ships. The API equivalent:
 
 ```bash
 curl -sk -X PUT https://localhost:3000/api/settings \
@@ -38,9 +41,14 @@ curl -sk -X POST https://localhost:3000/api/model-endpoints \
 ```
 
 `apiKey` is optional (most local servers don't check it). `authStyle`
-(`bearer` | `api-key` | `both`, default `both`) controls which auth header
-convention discovery uses — `both` works whether the endpoint is llama.cpp
-(ignores the header) or a cloud gateway like Azure (wants `api-key`).
+(`bearer` | `api-key`, default `bearer`) controls which auth header
+convention discovery uses: `bearer` is `Authorization: Bearer <key>`
+(llama.cpp, OpenAI-compatible servers, most gateways), `api-key` is the
+`api-key: <key>` header Azure AI Foundry wants. There is deliberately no
+"send both" option: measured against a real llama-swap server, a request
+carrying both headers hung indefinitely. `baseUrl` must be `http(s)`, carry
+no embedded credentials, and may not point at a link-local or cloud-metadata
+address; discovery re-checks the address the name actually resolves to.
 
 Discover its available models:
 
@@ -63,17 +71,36 @@ curl -sk -X POST https://localhost:3000/api/sessions/<sessionId>/custom-model \
 ```
 
 This computes the CLI-specific env vars / config for that session's mode
-(see the recipe table in `deployment_plan.md`) and **restarts the session's
+(see the recipe table in `custom-model-endpoints-plan.md`) and **restarts the session's
 CLI process in place** — same pane, same tmux session, fresh env. That
 restart is necessary, not incidental: every supported harness reads its
 endpoint config at process start, not per-turn, so there is no live
-hot-swap. Clear back to the harness's native cloud default with:
+hot-swap. A Claude session is relaunched with `--resume <conversation> ||
+--session-id <id>`, so it continues the conversation it was on; pi, omp and
+grok are relaunched with the `--model` value that selects the injected
+provider (`custom/<modelId>` for pi and omp, `codeman-custom` for grok),
+since for those three the config file alone does not switch the model.
+**Remote (SSH) and Docker sessions are refused** (400) for now: their restart
+reattaches the durable remote/in-container tmux rather than relaunching the
+agent, so the selection would report success and change nothing.
+
+Clear back to the harness's native cloud default with:
 
 ```bash
 curl -sk -X POST https://localhost:3000/api/sessions/<sessionId>/custom-model \
   -H 'Content-Type: application/json' -d '{"clear": true}'
 ```
 
+Clearing also removes the env vars the selection injected from the tmux
+session (they persist there and would otherwise be inherited by the
+relaunched CLI) and deletes the per-session config directory
+(`~/.codeman/custom-model-configs/<sessionId>`, written 0600 because pi and
+omp embed the API key in it). That directory is also removed when the
+session is deleted. The selection survives a Codeman restart: the endpoint
+id, model and injected key NAMES are persisted, the values are re-derived
+from the endpoint store on recovery, and the pane keeps running against the
+endpoint in between because tmux retains its environment.
+
 **New sessions always default back to the harness's native backend.** A
 custom-endpoint selection is a per-session choice, never a sticky global
 default — starting a fresh session doesn't inherit whatever the last one was
@@ -101,7 +128,7 @@ automatically). Results:
   gets a consistent `HTTP_404`. Root cause not identified; best-effort only.
 - **Antigravity** — no known custom-endpoint mechanism at all; unsupported.
 
-See the confidence table in `deployment_plan.md` for the full detail behind
+See the confidence table in `custom-model-endpoints-plan.md` for the full detail behind
 each result. `scripts/test-local-llm-harnesses.ts` is the standalone script
 used to check a harness against a real endpoint outside the web UI
 entirely; see its own `--help` for usage.
@@ -115,6 +142,6 @@ non-granted multi-user owner cannot set one directly via the generic
 `envOverrides` API field — only through this feature's own route, which
 computes the value from an admin-configured, SSRF-guarded endpoint rather
 than trusting arbitrary client input. See the "Multi-user security
-hardening" section of `deployment_plan.md` for the full reasoning; several
+hardening" section of `custom-model-endpoints-plan.md` for the full reasoning; several
 of these were reachable via the generic `envOverrides` field even before
 this feature existed, and building this surfaced and closed that gap.