fix(release): the seven findings from the pre-release review of the whole tree

A full review of the release tree found seven things, and four of them were mine.

**The gate was red, and I put it there.** Splitting `confirmed` into `confirmedContext`
and `confirmedSwap` changed the wire field without moving three assertions that check
it: `custom-model-one-shot-launch.test.ts` and two in `custom-model-run-menu-ui.test.ts`
(the swap modal and the context modal, each of which already receives exactly the right
per-question flag). Moved, with the titles.

**Worse, my own tests for the split never ran.** The four cases in
`session-custom-model.test.ts` that exist specifically to pin it call `mockRunning()`,
which was declared inside a sibling `describe`, so they threw a ReferenceError during
setup. The split would have shipped with no passing server-side coverage while the gate
reported the failure as four broken tests rather than as four tests that were never
written. `mockRunning` is hoisted to the outer describe.

**The submit verifier pressed Enter into shell panes.** `#455`'s SubmitVerifier resolved
its composer glyph as `promptGlyph ?? '❯'`, and only claude and codex declare one, so
the other eight modes fell back to claude's `❯`. That is also starship's default shell
prompt, and pure's, and spaceship's, and p10k lean's. On such a shell the line
`❯ npm run build` sits on screen for as long as the command runs, the verifier reads it
as an unsubmitted prompt, and re-presses Enter into the running program's stdin up to
nine times on its 2s..60s schedule. Mostly a stray newline; not harmless against a y/N
prompt, `read -p`, an installer or a pager, where it takes the default. The module's own
fileoverview already stated the rule this broke. Now `?? ''`, which
`promptStillInComposer()` already treats as inert, so the verifier runs only for a CLI
that actually declares a composer.

**My #451 dedent removal left a count behind**: "Two rules keep it honest" introducing
three numbered rules.

The rest is documentation the split outran. `confirmedContext`/`confirmedSwap` appeared
in no doc at all, while `docs/api-reference.md` (the SemVer-covered contract) still told
an integrator to retry with `confirmed: true` for both questions, which is precisely the
thing the split exists to stop. Documented there, in `docs/custom-model-endpoints.md`
and in CLAUDE.md. The custom-model changeset gained the split and the `CLAUDE_CONFIG_DIR`
multi-user consequence, both user-visible and both previously absent, and #454's gained
the one exception to its own claim: a Custom Endpoints launch ignores the Instance count
stepper and always starts one session.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/custom-model-endpoints.md

@@ -227,7 +227,7 @@ already pointed at the endpoint. No restart, because there was never a
 native-backend launch to restart away from. Runs the same llama-swap
 conflict check as the restart route (below) — a `409`-shaped
 `{requiresConfirmation, currentlyLoadedModel, affectedSessions}` response
-with no session created, resolved by retrying with `confirmed: true` — and
+with no session created, resolved by retrying with `confirmedSwap: true` — and
 is refused the same way for a remote or Docker case. This is what the
 Run-menu picker uses for opencode, Codex, Gemini, Pi, Grok, DeepSeek and OMP;
 Claude still uses the restart route below (see "The Run-menu picker" above
@@ -350,7 +350,8 @@ which can take anywhere from a few seconds to well over a minute:
   session's own selection** is using it, the apply returns
   `{requiresConfirmation: true, currentlyLoadedModel, affectedSessions}`
   instead of silently switching — nothing is applied or created yet.
-  Retrying with `confirmed: true` skips the check. Switching with nothing
+  Retrying with `confirmedSwap: true` skips the check (the legacy `confirmed: true`
+  still means both questions). Switching with nothing
   else affected proceeds immediately; this is a warning about disrupting
   another session, never a gate on the switch itself.
 - **Actually starting the load.** llama-swap has no "switch model" admin
@@ -413,7 +414,7 @@ contextLength, minSafeContextTokens}` instead of applying — nothing is
 restarted or created yet. A context length that was never discovered at
 all skips the check entirely (nothing to compare, so it fails open rather
 than warning on every model an endpoint hasn't reported a size for).
-Retrying with `confirmed: true` launches anyway.
+Retrying with `confirmedContext: true` launches anyway (the legacy `confirmed: true` still means both questions).
 
 The Run-menu picker shows this as an in-app modal
 (`#customModelContextWarningModal`, matching the llama-swap conflict