Emit a sonnet_4_6 key in claude_models so both Sonnet generations are selectable

[dgokeeffe]

Context

Omnigent pins Claude Code's /model tier aliases from the claude_models map
ucode writes to ~/.ucode/state.json:

"claude_models": {
  "fable":  "databricks-claude-fable-5",
  "opus":   "databricks-claude-opus-4-8",
  "sonnet": "databricks-claude-sonnet-...",
  "haiku":  "databricks-claude-haiku-4-5"
}

Each key maps to one ANTHROPIC_DEFAULT_*_MODEL env var, so each family alias
can carry only one model id. With both claude-sonnet-5 and
claude-sonnet-4-6 now in active use (Sonnet 5 is not yet available in every
region/workspace), one Sonnet generation currently shadows the other in the
picker.

omnigent-ai/omnigent#1981 adds a consuming side for a second Sonnet: an
optional sonnet_4_6 key in claude_models is pinned to Claude Code's single
custom /model slot via ANTHROPIC_CUSTOM_MODEL_OPTION (+ _NAME for the
picker label), alongside sonnet pinned to the newest Sonnet.

Request

When a workspace's gateway serves both Sonnet generations, please emit:

"claude_models": {
  "sonnet":     "<newest Sonnet endpoint, e.g. databricks-claude-sonnet-5>",
  "sonnet_4_6": "<Sonnet 4.6 endpoint, e.g. databricks-claude-sonnet-4-6>",
  ...
}

• sonnet should track the newest Sonnet generation (today: Sonnet 5).
• sonnet_4_6 should be present only when the workspace actually serves a
  Sonnet 4.6 endpoint; omnigent treats a missing key as a no-op, so this is
  backward- and forward-compatible.
• Workspaces serving only one Sonnet generation keep the current single
  sonnet entry pointing at whichever generation they have.

Why the key is sonnet_4_6

Claude Code's family env vars are a fixed set (FABLE/OPUS/SONNET/HAIKU)
plus exactly one extra selectable slot (ANTHROPIC_CUSTOM_MODEL_OPTION) — see
https://code.claude.com/docs/en/model-config. There is no way to expose two
Sonnet ids under the family alias, so the older generation rides the custom
slot, and the key names the concrete version it pins.