feat(custom-model): launch directly on the endpoint, no restart, for 7 of 8 CLIs

Fixes the visible double-launch reported on Codex: picking a custom-model
Run-menu entry launched natively first, waited for it to settle, then
restarted it in place with the endpoint applied. Necessary for the design at
the time, but visibly a native boot immediately followed by a second one -
worst on a CLI whose TUI fully reinitializes on a restart, confirmed live on
Codex.

POST /api/quick-start gains an optional customModel field
({endpointId, modelId, confirmed?}). When present, the route mints the
session's id itself (crypto.randomUUID()) before constructing it, computes
the same injection the existing POST /api/sessions/:id/custom-model route
computes (including the llama-swap conflict check from the last commit -
same {requiresConfirmation, currentlyLoadedModel, affectedSessions} shape,
no session created until confirmed), and launches the session already
pointed at the endpoint: env vars via the constructor, and the launchModel
override merged onto piConfig/grokConfig/ompConfig using the registry's own
launch.legacyConfigField the same way session.ts's restart path already
does. No restart at all - setCustomModel() afterward is bookkeeping only.

Wired into 7 of 8 launch functions (session-ui.js): openCode, codex, gemini,
pi, grok, deepseek, omp. Claude stays on the original launch-then-restart
path for now: its own --resume-based restart is far less jarring than the
other seven's, and runClaude()'s multi-tab launch plus docker-config-drift
confirm/retry loop make folding it into the one-shot path separate,
higher-risk work than the other seven's each-a-single-simple-launch shape.

Also fixes a pre-existing 'mode === omp' branch flagged by the CLI-id
static guard (test/cli-registry-no-id-branching.test.ts) - the ompConfig
launchModel merge is the same 'legacy <Mode>Config plumbing' category as
the six sibling branches already allowlisted there, just newly literal
where it was previously only inside resolveOmpConfigForCreate's own check.

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

docs/wiki/Custom-Model-Endpoints.md

@@ -52,12 +52,15 @@ small dialog asks which one to use for this launch before starting the session;
 endpoint's default model, if set, is marked but not auto-picked, so a launch can deliberately
 use a different one without changing the saved default.
 
-Applying a selection **restarts the harness's process in place** — same tab, same
-conversation where the harness supports resuming one, fresh environment. That restart is
-necessary, not incidental: every supported harness reads its endpoint config at process
-start, never per turn, so there is no live hot-swap while a turn is running.
+**For opencode, Codex, Gemini, Pi, Grok, DeepSeek and OMP, picking an entry launches
+straight onto the endpoint** — no restart, because the endpoint is applied before the
+session's process ever starts. **Claude still restarts the harness's process in place** —
+same tab, same conversation (`--resume`) — after a normal native launch, since that restart
+is far less jarring for Claude than for the other seven, whose own TUI can fully
+reinitialize on a restart. Either way, every supported harness reads its endpoint config at
+process start, never per turn, so there is no live hot-swap while a turn is running.
 
-Picking an entry that launches a **brand-new** session waits (up to 20 seconds) for it to
+Picking an entry that launches a **brand-new** Claude session waits (up to 20 seconds) for it to
 finish its own startup before applying — a freshly started CLI reports itself as busy for its
 boot sequence, and applying to a genuinely busy session is refused so a real, in-progress
 turn is never interrupted out from under you. A session that is still busy after that wait