feat(custom-model): generate Run-menu entries from saved endpoint profiles

Follow-up to #393, picking up the work Ark0N invited in his merge comment:
"generate those entries from the saved profiles rather than a fixed
duplicate per harness, and put it in a follow-up PR so this one stays the
backend... The Run-menu picker is yours if you want it."

Adds the frontend surface the backend has been waiting on:

- Run menu: a "Custom Endpoints" section lists one entry per (harness that
  supports customModelInjection, saved endpoint) pair, e.g.
  "Claude Code (llama.cpp)". The harness list comes from
  window.__codemanCustomModelClis, injected at page render straight off the
  CLI registry's own capabilities (never a hardcoded id list in the
  frontend), so a CLI whose injection recipe lands later appears with no
  frontend change. Picking an entry runs that harness's own existing run*()
  function unmodified (case creation, env overrides, everything, forced to
  a single instance) and then applies the endpoint's default model to the
  session it creates via the existing POST /api/sessions/:id/custom-model
  route. Entries are hidden for a remote/docker active case, since that
  route already refuses both.
- Settings: App Settings -> Models gets a "Custom model endpoints" group
  wiring up the customModelEndpointsEnabled toggle (declared since #393,
  read by nothing until now) plus CRUD against the existing
  /api/model-endpoints routes: list, add/edit (inline form), delete,
  discover models.
- Backend: CustomModelHost gains an optional defaultModelId, the model the
  picker applies with no further choice per endpoint (one generated menu
  entry per CLI+endpoint pair, not per CLI+endpoint+model). The route
  refuses a value that isn't one of the endpoint's own discovered models,
  and a fresh discovery drops a default that no longer appears rather than
  carrying an invalid one forward.

Docs: docs/custom-model-endpoints.md describes the new picker and settings
panel; CLAUDE.md's Custom Model Endpoint Profiles entry drops the
"backend-only" status note and documents the picker's generation mechanism.

Tests: four new route tests cover defaultModelId validation, acceptance,
and the drop/keep behaviour across a re-discovery; a new render-index-html
test pins the __codemanCustomModelClis injection (present, agent CLIs
supporting the capability, antigravity and shell excluded) and its
solo-window skip. No browser test was added for the Run-menu picker itself
or the settings CRUD panel (this box has no tmux, so the live server used
by test:browser/test:mobile could not be exercised here) -- worth a
Playwright pass before merge, same as any other frontend PR.

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

docs/custom-model-endpoints.md

@@ -11,20 +11,21 @@ company gateway) — anything answering `GET /v1/models` and
 recipe confidence table, and security reasoning:
 [`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
-> restart route). The toolbar picker / settings UI described below as the
-> intended surface is **not yet built** — until it lands, use the HTTP API
-> directly (examples below). Antigravity has no known custom-endpoint
-> mechanism and is not supported.
+> **Status**: fully wired end to end — registry capability, the injection
+> engine, the endpoint store + discovery route, the session restart route,
+> a settings-panel CRUD surface, and the Run-menu picker described below.
+> Antigravity has no known custom-endpoint mechanism and is not supported.
+> The HTTP API (examples below) still works directly and is what the picker
+> itself calls under the hood.
 
 ## Turning it on
 
-App Settings → Agents & CLIs → **Custom Model Endpoints** (synced setting
-`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:
+App Settings → Models → **Custom model endpoints** (synced setting
+`customModelEndpointsEnabled`, default **OFF**). Turning it on does two
+things: it reveals the endpoint list/add/edit/discover panel in that same
+settings section, and it makes the Run menu offer a generated entry per
+(harness, endpoint) pair — see "The Run-menu picker" below. The API
+equivalent:
 
 ```bash
 curl -sk -X PUT https://localhost:3000/api/settings \
@@ -34,6 +35,9 @@ curl -sk -X PUT https://localhost:3000/api/settings \
 
 ## Adding an endpoint
 
+Via App Settings → Models → Custom model endpoints → **+ Add endpoint**, or
+directly:
+
 ```bash
 curl -sk -X POST https://localhost:3000/api/model-endpoints \
   -H 'Content-Type: application/json' \
@@ -62,6 +66,34 @@ configured, `PUT`/`DELETE /api/model-endpoints/:id` update or remove one.
 Endpoint management is admin-only in multi-user mode, same as remote/docker
 hosts — these are machine-level infra, not per-user settings.
 
+`defaultModelId` names which discovered model the Run-menu picker applies
+for that endpoint with no further choice — the settings panel's Edit form
+exposes it as a select populated from the endpoint's own discovered
+`models`, and the route refuses a value that isn't one of them. Leaving it
+unset falls back to the first discovered model; re-discovering drops a
+default that no longer appears in the fresh list rather than carrying an
+invalid one forward.
+
+## The Run-menu picker
+
+With the setting on and at least one endpoint carrying a usable default
+model (either an explicit `defaultModelId` or just one discovered model),
+the toolbar's Run dropdown grows a **Custom Endpoints** section: one entry
+per (harness that can redirect to a custom endpoint, saved endpoint) pair,
+e.g. "Claude Code (llama.cpp)". The harness list is read off the CLI
+registry's own `capabilities.customModelInjection` at page render
+(`window.__codemanCustomModelClis`, `server.ts`) — never a hardcoded id list
+in the frontend — so a CLI whose injection recipe lands later shows up with
+no frontend change, and Antigravity (`unsupported`) never does.
+
+Picking an entry runs a single session on that harness exactly the way its
+own Run-menu entry would (same case creation, env overrides, everything),
+then immediately applies the endpoint's default model to it via the route
+below. It is a one-off "try this endpoint" action, not a sticky mode: the
+plain Run button still means "this harness, native cloud" afterward.
+Entries are hidden entirely for a remote or Docker active case, since the
+apply route refuses both (see the next section).
+
 ## Applying a model to a session
 
 ```bash