[Story]: governance-auth should write ANTHROPIC_CUSTOM_MODEL_OPTION + context window instead of relying on model discovery

### Type
Story

### Summary

`governance-auth configure` should write `ANTHROPIC_CUSTOM_MODEL_OPTION` (plus its `_NAME`
and `_DESCRIPTION`) and a matching `CLAUDE_CODE_MAX_CONTEXT_TOKENS` into Claude Code's
`settings.json`, so a developer gets a working, correctly-sized gateway model in the
`/model` picker with no gateway change, no auth exemption and no catalog endpoint.

This is the pragmatic replacement for gateway model discovery, which was investigated and
does not work here.

### Why discovery does not solve this

Findings, all measured or quoted from
and
:

1. **The filter excludes every model this platform serves.** Claude Code keeps a discovered
entry only when its `id` contains `claude` or `anthropic`, case-insensitively. All 21
live ids (`adorsys-coder`, `mimo-v2p5`, `kimi-k2.7-code`, …) contain neither.
2. **Prefixing to pass the filter breaks routing.** Verified in production:
`model=anthropic/adorsys-coder` → `404 No matching route found…`, while
`model=adorsys-coder` reaches routing. Claude Code sends the id back verbatim.
3. **There is no client-side aliasing.** `modelOverrides` keys must be real Anthropic model
IDs and "unknown keys are ignored"; `ANTHROPIC_CUSTOM_MODEL_OPTION` passes its value
through unchanged. Nothing can strip a prefix.
4. **A `claude-`-containing alias would be worse.** Claude Code resolves any id *containing*
a Claude model name to that model and applies **its** context window and capabilities;
`CLAUDE_CODE_MAX_CONTEXT_TOKENS` cannot correct that case.
5. **Discovery conveys only `id` and `display_name`.** No context length, no capabilities.
`ANTHROPIC_DEFAULT_*_MODEL_SUPPORTED_CAPABILITIES` "have no effect behind an
`ANTHROPIC_BASE_URL` gateway".
6. **Context window is per-session and global.** One `CLAUDE_CODE_MAX_CONTEXT_TOKENS` for
the whole session; switching models in the picker does not change it. A 21-model picker
would share one assumed window — wrong for most of them.

`ANTHROPIC_CUSTOM_MODEL_OPTION` sidesteps 1–4 entirely: no filter, no validation ("you can
use any string your API endpoint accepts"), and the plain id is what the gateway already
routes. Because it is **one** model, 5–6 stop being contradictions: a single declared
context window is correct for it.

### Scope

- `configure` writes, when configured: `ANTHROPIC_CUSTOM_MODEL_OPTION`,
`ANTHROPIC_CUSTOM_MODEL_OPTION_NAME`, `ANTHROPIC_CUSTOM_MODEL_OPTION_DESCRIPTION`,
`CLAUDE_CODE_MAX_CONTEXT_TOKENS`.
- New config options through the existing five-layer precedence (flag / env / per-user file
/ machine-wide file / compiled default) — the machine-wide file is the natural home, so an
operator sets the org's model once.
- Off by default: absent config writes none of these keys.

### Acceptance criteria

- [ ] With the options set, `configure` writes all four keys and a developer can select the
model from `/model` and complete a real request — verified end to end, not by
inspecting `settings.json`.
- [ ] With them unset, `settings.json` gains none of the keys (no empty values written).
- [ ] `CLAUDE_CODE_MAX_CONTEXT_TOKENS` is only written when the model option is also set —
a global window declared against no particular model is a footgun.
- [ ] The model id is written verbatim, with no prefixing or rewriting.
- [ ] Documented in the runbook, including that the window is session-global and applies to
whatever model the session ends up on.
- [ ] No new option uses clap `default_value`/`default_value_t` (ADR-0012 §2 trap).

### Not in scope

- `availableModels` (a managed-settings allowlist) — worth its own decision; note the docs
say a custom option must also appear in that allowlist when it is set.
- Removing the `/anthropic/v1/models` catalog (ai-helm#1031). It is inert with
`idPrefix: ""` (ai-helm#1038) and becomes useful only if the gateway ever routes
claude-ish aliases.