[Bug]: BYOK upstream 429 collapses to bare 50113 in TUI — upstream message lost (but visible via mcode exec), wrong code class (50111 expected) #482

Summary

When a BYOK custom_provider upstream fails (HTTP 429 with a queue-position body, from new-api-style relay stations), the TUI shows only error code 50113 (LLM_UPSTREAM_ERROR) with no upstream message, so the user cannot tell "queued / saturated" from "broken key / network". Two related problems:

1. The upstream error body is dropped on the TUI error path.
2. HTTP 429 is classified as 50113 (generic upstream error) instead of 50111 (LLM_RATE_LIMITED), so rate-limit-aware UI/retry paths don't trigger.

Evidence

• mcode exec does surface the full upstream text, e.g.:
  BYOK provider custom_provider:<site> upstream error: OpenAI API error (429): All concurrency slots are busy. You are number 73 of 78 in the queue, please retry in about 5 seconds
  → the information exists at the transport layer; the interactive (TUI/desktop) error path discards it.
• In the bundled chunk (0.6.8): LLM_RATE_LIMITED:50111, LLM_AUTH_ERROR:50112, LLM_UPSTREAM_ERROR:50113 — 429 queue responses land in 50113.
• Nothing beyond the code is persisted in ~/.minimax/v2/observability logs either, so post-hoc diagnosis is impossible.

Repro

1. Configure a custom_provider with api: openai-responses pointing at a new-api relay that gates by concurrency slots (returns 429 + number X of Y in the queue when full).
2. Use that model interactively during congestion.
3. TUI error bubble shows only "50113" (or "连接失败"), no upstream message.

Expected

• Show the upstream message (redacted of anything sensitive) in the TUI error, like mcode exec already does.
• Map HTTP 429 to LLM_RATE_LIMITED (50111) so clients can back off / display "queued" state; queue position ("retry in about N seconds") maps naturally onto a Retry-After-style hint.
• At minimum, persist the raw upstream error line in the observability log for post-hoc diagnosis.