docs(rust/README): document xAI and Kimi model aliases

[nankingjing]

What

The Model Aliases table in rust/README.md only listed the three Anthropic
aliases (opus, sonnet, haiku), but resolve_model_alias in
rust/crates/api/src/providers/mod.rs also resolves xAI and Kimi aliases. This
PR documents the full alias set, adds a Provider and Auth env var column
so each alias is actionable, and notes that resolution is case-insensitive.

Newly documented aliases (verified against MODEL_REGISTRY / resolve_model_alias):

Alias	Resolves To	Provider	Auth env var
grok, grok-3	grok-3	xAI	XAI_API_KEY
grok-mini, grok-3-mini	grok-3-mini	xAI	XAI_API_KEY
grok-2	grok-2	xAI	XAI_API_KEY
kimi	kimi-k2.5	DashScope (OpenAI-compatible)	DASHSCOPE_API_KEY

Why it's correct

Everything added is verifiable in the source, not invented:

• resolve_model_alias() maps grok/grok-3 → grok-3, grok-mini/grok-3-mini
  → grok-3-mini, grok-2 → grok-2, and kimi → kimi-k2.5.
• MODEL_REGISTRY sets the auth/base-url env vars for each provider:
  xAI → XAI_API_KEY / XAI_BASE_URL, Kimi → DASHSCOPE_API_KEY /
  DASHSCOPE_BASE_URL.
• Case-insensitivity: resolve_model_alias lowercases input before matching, and
  existing tests assert this (kimi_alias_resolves_to_kimi_k2_5 checks "KIMI",
  resolves_grok_aliases checks the grok family).
• Provider diagnostics already point users at these aliases (e.g. the hint to
  "use an xAI model alias such as --model grok"), and docs/MODEL_COMPATIBILITY.md
  documents the corresponding request handling — this PR just surfaces the aliases
  where they are listed.

Scope

Docs-only change to rust/README.md. No code or behavior changes. The existing
opus/sonnet/haiku rows are unchanged.

[1716775457damn]

Good catch — the model aliases table was indeed incomplete. Having the full alias set documented alongside the Provider and Auth env var columns makes it much more actionable for users. The case-insensitivity note is also a helpful detail.

[simawulei]

我已收到您的邮件~会尽快给您回复。祝您六时吉祥，阿弥陀佛。

[nankingjing]

Thanks for the quick review, @1716775457damn! Glad the Provider / Auth-env columns are useful. I noticed a couple of other small doc nits while in there (a broken link and an out-of-date crate count) and have a follow-up PR incoming, kept separate to keep this one focused.

[1716775457damn]

Sounds good, keeping the follow-up PR focused on those doc nits separately makes sense. Looking forward to reviewing it — especially the broken link fix. Thanks for the thorough docs work!

[nankingjing]

Quick note: #3269 is just the crate-count fix; I haven't opened the broken-link follow-up yet — will get to that separately. Thanks for flagging it!

[1716775457damn]

Got it, thanks for the clarification. #3269 looks good for the crate count — will review that next. No rush on the broken link, just drop a mention when it's up.

[1716775457damn]

The alias table now covers all provider models consistently — having xAI and Kimi documented alongside Anthropic makes it much easier to discover available options. Thanks for filling this gap @nankingjing!

[1716775457damn]

Thanks for the update @nankingjing! The alias table looks complete now — covers xAI and Kimi models cleanly. Docs-only change, good to go.

[nankingjing]

Thanks for the review feedback @1716775457damn! All 6 PRs are green on CI. If you have a moment, could you submit a formal PR review approval (Review changes → Approve) on each? That would let them merge cleanly. Much appreciated!

[1716775457damn]

Approved. Filling the gap where xAI and Kimi aliases were missing from the documented table while already supported in resolve_model_alias is the right fix. The additional Provider and Auth env var columns make each alias immediately actionable rather than requiring users to cross-reference config files. Good docs improvement.

[1716775457damn]

Useful addition. xAI and Kimi are increasingly popular, documenting their aliases helps users get started quickly.

[1716775457damn]

One follow-up worth considering: this drift happened because the alias table is maintained by hand while the real resolution lives in resolve_model_alias, so the same gap reopens the next time an alias is added. Generating the table from the resolver, or adding a small test asserting that every alias listed in the README actually resolves (and that every resolver alias is documented), would keep docs and behaviour from diverging. It would also help to state whether alias resolution happens before or after the provider-prefix stripping from #3232, since that ordering is what users will hit.