ACP thought_level option ignores model support_efforts: kimi-code/k3 advertises only on, graded values silently dropped

What feature would you like to see?

Expose model thinking-effort levels (support_efforts) through the ACP thought_level config option.

For managed kimi-code models that declare graded effort levels, the ACP adapter collapses the thinking config option to a single "on" value:

• config.toml declares kimi-code/k3 with support_efforts = ["low","high","max"] and default_effort = "high". The TUI /effort picker correctly offers the graded levels for this model.
• Over ACP (kimi acp, 0.27.0), session/new returns the thinking config option (category: "thought_level") with options: ["on"] only — not even off. Same after switching models via session/set_config_option or the unstable session/set_model, including the resulting config_option_update notification.
• Sending a graded value (low / high / max) via session/set_config_option is silently ignored: currentValue stays "on", no error is returned.

The capability itself works end-to-end outside ACP: sessions honor [thinking] effort from config.toml — an ACP-spawned session with K3 sends model requests carrying thinkingEffort: "max". Only the ACP surface cannot discover or change it.

Ask: advertise the active model's ordered support_efforts (plus off where applicable) as the thinking config-option options, updating on model change, and apply graded values passed to session/set_config_option live. Keeping on/off as accepted aliases (on = model default) would stay backward compatible with existing clients.

This would let ACP clients (Zed, JetBrains, and other IDE integrations) offer a per-session effort picker instead of requiring users to edit the global config.toml and respawn sessions.

Additional information

• Related: #1486 asks for graded reasoning-effort over session/set_config_option generically; this report adds the managed-kimi-code-model angle, where the adapter does not even advertise off and graded writes fail silently (no error), which makes client-side fallbacks impossible to detect.
• Repro (0.27.0, Windows): kimi acp → initialize → session/new → inspect configOptions; then session/set_config_option {configId:"model", value:"kimi-code/k3"} and session/set_config_option {configId:"thinking", value:"high"} → currentValue remains "on".
• Workaround currently required: set [thinking] effort in ~/.kimi-code/config.toml globally and start a new ACP session; verified effective via the session wire log ("thinkingEffort":"max").

Start with the kimi acp flow and reproduce the behavior through session/new, session/set_config_option, and the unstable session/set_model using the issue's K3 configuration. Trace how config.toml values such as support_efforts and default_effort become the ACP thinking option. Done means the active model advertises its ordered effort levels and applicable off value, model changes update them, and graded values apply live while on and off remain compatible aliases.