feat(kimi): add Kimi K3 256K (kimi-k3-256k) to the model catalog

[robertn702]

Summary

Kimi announced k3-256k, the 256K-context variant of Kimi K3. Per the upstream announcement, k3 (1M) consumes about twice as much quota as k3-256k while delivering the same results within 256K of context, and k3-256k is the only K3 model available at the Moderato tier.

This adds the entry to the kimi section of models.json, mirroring kimi-k3:

• context_length: 262144 (256K, per the upstream spec)
• max_completion_tokens: 65536
• thinking levels low/high/max with zero_allowed: false
• description notes image-only input (no video), per the announcement

The entry is identical to the one in router-for-me/CLIProxyAPI#4617.

Why this repo needs the change too

CLIProxyAPI#4617 adds kimi-k3-256k to the embedded catalog (internal/registry/models/models.json). That alone does not reach running instances: unless started with --local-model, CLIProxyAPI fetches this repo's models.json at startup and every 3h, and the fetch replaces the per-provider list rather than merging into it.

Verified locally against CLIProxyAPI main (a80e808) — with the row added to the embedded catalog only, a normal start logs:

startup model refresh completed from .../router-for-me/models/.../models.json, changes detected for providers: [kimi]

and kimi-k3-256k disappears from /v1/models. With --local-model it persists. So this repo is the path that actually reaches users.

Verification

No executor change is required. normalizeKimiUpstreamModel strips the kimi- prefix, so kimi-k3-256k → k3-256k upstream. Confirmed end-to-end against a live Kimi subscription with the catalog row in place:

POST /v1/chat/completions  {"model": "kimi-k3-256k", ...}
-> 200  {"model": "k3-256k", ..., "finish_reason": "stop"}

The response echoes the upstream ID k3-256k, confirming the request reached the 256K model and not k3.

Refs router-for-me/CLIProxyAPI#4612, router-for-me/CLIProxyAPI#4617