[Feature Request] Let theme = "auto" map dark/light to custom themes (e.g. theme_dark / theme_light)

Summary / 概要

theme = "auto" resolves to one of the two built-in palettes (dark / light) at startup. There is currently no way to make the auto switch resolve to custom themes. Please allow each side of auto to point at a user-defined theme, e.g.:

# ~/.kimi-code/tui.toml
theme = "auto"
theme_dark = "night-hc"    # custom theme from ~/.kimi-code/themes/night-hc.json
theme_light = "day-hc"     # custom theme from ~/.kimi-code/themes/day-hc.json

Motivation / 背景

I use Kimi Code mostly from a mobile terminal over Mosh. At night the built-in dark palette's dim tokens are very hard to read on a phone screen:

• textDim #888888, textMuted #6B6B6B, diffGutter #6B6B6B, diffMeta #888888, border #5A5A5A

The custom-theme feature (~/.kimi-code/themes/*.json) solves the readability problem — I maintain a high-contrast night-hc and a day-hc. But switching between them is fully manual (/theme or editing tui.toml + /reload-tui), while the terminal app itself already knows whether it is showing a dark or light background, and auto already detects that at startup (OSC 11 / DEC mode 996).

So the missing piece is only: let auto resolve to user-chosen palettes instead of being hardwired to the two built-in ones.

Current behavior (verified in 0.41.0)

• tui.toml theme accepts only auto | dark | light | custom theme name.
• auto picks one of the built-in palettes at startup, falling back to dark when terminal background detection is unavailable.
• Built-in palettes are hardcoded (src/tui/theme/colors.ts), and custom theme files named dark.json / light.json / auto.json are explicitly excluded from the picker via RESERVED_THEME_NAMES in src/tui/theme/custom-theme-loader.ts, so shadowing built-ins is impossible.

Proposed API

Any of these would work; the first seems most consistent with the existing flat tui.toml style:

1. Sibling keys (preferred): theme_dark / theme_light, honored only when theme = "auto"; values may be dark / light / any custom theme name. Unset keys keep the current built-in behavior.
2. Table form: theme = "auto" plus [theme.auto] dark = "night-hc", light = "day-hc".
3. Tuple form: theme = ["night-hc", "day-hc"] (dark, light), with auto detection.

In all forms, unknown/missing custom theme names should fall back to the corresponding built-in palette (matching the current "never get in the way" error philosophy), and mid-session terminal theme changes (mode 996 reporting) should ideally re-resolve the mapped custom theme, the same way auto re-resolves today.

Alternatives considered

• Manually switching via /theme — works, but is a daily chore across many sessions.
• A launcher wrapper that queries OSC 11 and rewrites tui.toml before start — fragile over Mosh and duplicates detection logic the CLI already has.

Environment

• Kimi Code 0.41.0, macOS (host), accessed from iOS terminal via Mosh.

Start in src/tui/theme/colors.ts and src/tui/theme/custom-theme-loader.ts, then trace the existing auto theme resolution and terminal background detection. Decide how the proposed theme_dark and theme_light settings fit the current configuration, preserve built-in fallback behavior, and verify that auto selects the configured palettes, including during mode 996 updates if supported.