Feature Request: Configurable git status/branch polling intervals for monorepo users

Feature Request

What feature would you like to see?

Make the Git status polling intervals (_GIT_BRANCH_TTL and _GIT_STATUS_TTL) configurable via environment variables or the global ~/.kimi/config.toml configuration file.

Current behavior:

In src/kimi_cli/ui/shell/prompt.py, these values are hard-coded constants:

_GIT_BRANCH_TTL = 5.0   # queries git branch every 5 seconds
_GIT_STATUS_TTL = 15.0  # queries git status every 15 seconds

Each Kimi CLI instance independently spawns git branch --show-current and git status --porcelain -b subprocesses on its own schedule. When multiple instances are running simultaneously in the same repository, they compete for .git/index.lock.

My use case & the problem:

I work in a large monorepo (~111,000 tracked files). I typically keep multiple Kimi CLI instances open at once—one per sub-project—via tmux sessions/windows/panes. This leads to:

1. Performance degradation: git status in this repo takes ~2–8 seconds. With 10–15 Kimi CLI instances, that's a sustained background load of repeated filesystem scans.
2. index.lock conflicts: When I run git commit or other git operations, I occasionally hit:

   fatal: Unable to create '.git/index.lock': File exists.
   Another git process seems to be running in this repository...
   

   The lock is held by one of the many git status --porcelain -b subprocesses spawned by Kimi CLI's prompt refresh.

Proposed solution:

Expose these two TTL values through one of (or both):

• Environment variables: e.g. KIMI_GIT_BRANCH_TTL, KIMI_GIT_STATUS_TTL
• Global config (~/.kimi/config.toml): e.g. a new [shell.git] or [ui] section:

  [shell.git]
  branch_ttl = 30.0
  status_ttl = 60.0
  

For monorepo users, being able to tune these from 5s / 15s up to 30s / 60s (or longer) would eliminate most of the lock contention and wasted CPU/IO without affecting users in smaller repos who are happy with the defaults.

Workarounds considered:

• Reducing the number of Kimi CLI instances — not practical; I need one per active project.
• Enabling core.fsmonitor — helpful for git status speed, but doesn't reduce the frequency of subprocess spawning from multiple independent Kimi CLI instances.
• Patching the source locally — works, but breaks on every update.

Additional information:

• The Config class in src/kimi_cli/config.py already supports nested Pydantic models, so adding a shell or ui section with these two float fields should be straightforward.
• For reference, the relevant code is in src/kimi_cli/ui/shell/prompt.py around lines 877–878 and 932–987.

Start with src/kimi_cli/ui/shell/prompt.py around lines 877–878 and 932–987, then inspect the nested Pydantic configuration models in src/kimi_cli/config.py. Trace how the prompt reads configuration and decide how the two TTL values should be exposed through environment variables or ~/.kimi/config.toml. Done means users can configure both polling intervals while the existing 5.0 and 15.0 defaults remain unchanged.