429 rate-limit gives no user feedback — CLI just spins for minutes (still on 0.28.1)

Summary

When a request hits a provider rate limit (HTTP 429), the CLI gives the user no indication of what's wrong — it just sits on the spinner and silently retries, so it looks like an eternal load / a frozen session. Nothing tells the user they've hit a usage/rate limit, and the Retry-After is never surfaced.

This looks like the same behavior as #1796 (closed) and #1860 (open), and it still reproduces on 0.28.1.

Environment

• kimi-code 0.28.1, macOS (arm64)
• Provider type = "kimi", base_url = https://api.moonshot.ai/v1, model kimi-k3

What happens

With a free-tier key that has hit its daily token cap, every prompt (even "hi") makes the CLI spin with no output. Sampling the process shows it idle in the event loop (waiting on the retry backoff) — no error, no message in the TUI, no visible log. Meanwhile the provider's 429 body is fully actionable:

HTTP/2 429   retry-after: <seconds>
{"error":{"message":"... reached organization TPD rate limit, current: <n>, limit: 1500000",
          "type":"rate_limit_reached_error"}}

None of that reaches the user, so from the outside it's indistinguishable from a network hang or a crash.

Request

Surface the 429 instead of an unexplained spinner:

• Show the provider's rate-limit message and the Retry-After value, and/or
• Fail fast after the first 429 rather than retrying silently.

Even a single line like Rate limited (daily token limit reached) — retry in Ns would remove the confusion. As-is it's easy to assume the CLI is broken.

Start by tracing the CLI's HTTP 429 handling, retry/backoff path, and spinner or TUI update described in the report. Reproduce with a rate-limited provider response, then make the user see the provider message and Retry-After value or an explicit failure, and verify the CLI no longer appears to hang silently.