fix(kimi): restore kimi-k3[1m] entry accidentally dropped in edd8a89

[sruckh]

Problem

kimi-k3 is currently the only Kimi K3 entry in the catalog, at context_length: 262144. The 1M variant kimi-k3[1m] is gone, so there is no way to get Kimi K3's full 1M context window through CLIProxyAPI.

This is a regression, not a design decision

The entry was added on purpose and removed by accident, all on 2026-07-18:

commit	time (UTC)	effect on kimi-k3[1m]
3a51061	07-16 13:58	kimi-k3 added at 1048576
39e46b6	07-18 10:24	split: kimi-k3 → 262144, kimi-k3[1M] added at 1048576
eb5a30c	07-18 10:34	renamed to lowercase kimi-k3[1m] ("Fix casing in Kimi K3 model ID")
edd8a89	07-18 15:02	entry deleted

edd8a89 is titled "Update Gemini model names by removing "Preview" from entries in models.json". It is +19 −38; five of its six hunks are Gemini display-name edits around lines 620–780, and the sixth silently drops all 19 lines of the kimi-k3[1m] block at line 2189. The deletion is unrelated to the commit's stated purpose and has no accompanying message — it reads as a bad rebase/merge rather than an intentional removal, especially given the entry had been deliberately created and then carefully renamed just 4.5 hours earlier.

This PR restores exactly those 19 lines (+19 −0, the precise inverse of that hunk).

The consuming code already supports it

CLIProxyAPI's Kimi executor has first-class, tested handling for the suffix — internal/runtime/executor/kimi_executor.go:

// It strips CLIProxyAPI "kimi-" prefix and any Claude Code "[1m]" context
// suffix, so the upstream API receives IDs like "k3(1024)" instead of "kimi-k3[1m](1024)".
if strings.HasSuffix(strings.ToLower(base), "[1m]") {
    base = base[:len(base)-len("[1m]")]
}

with table tests in kimi_executor_test.go covering kimi-k3[1m] → k3, Kimi-K3[1M] → k3, k3[1m] → k3, and kimi-k3[1m](1024) → k3(1024). So the routing path is complete and the suffix is stripped before the upstream call; only the catalog entry that makes the ID resolvable is missing. Without it the registry lookup fails and the model is unreachable.

Why 1048576 is the correct value for this variant

• Moonshot's own Kimi K3 quickstart: "native visual understanding and a 1M-token context window", and "Kimi K3 offers a 1M-token context and uses flat pay-as-you-go pricing — there is no tiering by context length."
• Kimi Code's model list — the subscription the OAuth credential uses — offers Kimi K3 at 1M alongside a separate Kimi K3-256k model, confirming 256K is a distinct lesser variant rather than K3's ceiling.
• OpenRouter lists moonshotai/kimi-k3 at 1M.

Keeping both entries preserves the two-tier split introduced in 39e46b6: kimi-k3 stays conservative at 256K, and kimi-k3[1m] is the explicit opt-in for the full window.

Verification

• models.json parses cleanly; no duplicate model IDs in any provider array.
• Diff is +19 −0, byte-identical to the block removed in edd8a89.
• Reproduced the symptom against CLIProxyAPI v7.2.100: the Anthropic-shape /v1/models reports max_input_tokens: 262144 for Kimi K3, while Gemini entries correctly report 1048576 — so the metadata pipeline is fine and only the catalog value/entry is at fault.

🤖 Generated with Claude Code

Rollout requires no release

internal/registry/model_updater.go fetches this catalog at runtime from raw.githubusercontent.com/router-for-me/models/refs/heads/main/models.json on a 3-hour refresh ticker (the embedded copy is only a startup fallback), so merging this PR propagates to running CLIProxyAPI instances on their next refresh or restart — no new image release needed.

One deliberate deviation from the deleted block

The restored entry is byte-identical to what edd8a89 deleted except its display_name, changed from "Kimi K3" to "Kimi K3 (1M)". Both kimi-k3 and kimi-k3[1m] otherwise render identically as "Kimi K3" in client model pickers, making the 256K and 1M variants indistinguishable.

[sruckh]

Not even sure this is even accurate. In the kimi client kimi-k3 gives me the 1M context window, but within CLIProxyAPI I only get about 200k. I thought I had the full 1M context before, although not positive.