Summary

Translate DeepSeek 429 into a user-friendly concurrency-limit hint, and clarify that the rateLimit.rpm config is a client-side self-throttle (not a DeepSeek-enforced cap). Closes #1522.

Scope decision (intentionally narrow)

The "new rate limit" docs the issue references are concurrency-based: 500 in-flight requests per account for deepseek-v4-pro, 2500 for deepseek-v4-flash, summed across all API keys on the account. A single-user CLI doing one turn at a time can never approach this — only really hit when:

• the user has 3+ reasonix processes sharing one key, or
• a spawn_subagent parallel fan-out + nested subagents pile up beyond 500 in flight

So this PR is only about telling the user what's happening when 429 does fire. Explicitly not in scope:

• Implementing client-side concurrency tracking — pointless when DeepSeek already enforces it server-side and our single-turn loop can't saturate it on its own.
• Adding user_id parameter support — useful for multi-tenant scenarios (dashboard, cc-connect bridge), but per RFC RFC: Chat-platform bridge (Feishu / WeWork / WeChat) #410 chat-bridge work lives outside core. Reasonix-core stays single-user.
• Keep-alive parsing — already handled (client.ts:117-126 comment confirms SSE comments and non-stream empty lines are invisible to our parsers).
• 10-min server-side queue timeout — already covered by the existing 11-min client timeout.

What this PR does

1. Friendly 429 error message

src/loop/errors.ts: add 429 → t("errors.concurrency429", { inner }) alongside the existing 401/402/422/400 cases.

src/i18n/{EN,zh-CN}.ts + types.ts: new errors.concurrency429 key. Names the actual caps (500 pro / 2500 flash), identifies the likely cause (another reasonix process on the same key, or a fan-out that overshot), and points at the remediation (wait + retry, reduce parallelism, or request expansion at platform.deepseek.com).

Before:

DeepSeek 429: {"error":{"message":"Too Many Requests, please reduce concurrency"}}

After:

DeepSeek concurrency limit hit (429): Too Many Requests, please reduce concurrency. The account has too many in-flight requests (cap: 500 for v4-pro, 2500 for v4-flash, summed across API keys account-wide). Usually means another Reasonix process is sharing the same key, or a parallel subagent fan-out overshot. Wait a few seconds and retry, reduce parallelism, or request a higher cap at https://platform.deepseek.com.

2. Clarify rateLimit.rpm docstring

src/config.ts: RateLimitConfig.rpm is a client-side self-throttle paced by a min-interval timer — it never mapped to a DeepSeek-enforced cap (DeepSeek has never published an RPM ceiling). Docstring now spells that out so users don't think setting rpm: 60 does anything DeepSeek-related.

Test Plan

• tests/loop-error.test.ts — new case: DeepSeek 429: {...} → contains "concurrency limit" + "500" + "2500" + the inner reason + the platform URL
• npx vitest run tests/loop-error.test.ts tests/comment-policy.test.ts — 38 pass
• npx tsc --noEmit — clean
• npx biome check on touched files — clean
• npm run verify via pre-push hook — green

Test Plan (manual)

Not run — no easy way to actually trigger 429 from a single CLI process against DeepSeek's real concurrency cap without spinning up 500+ pro requests. The unit test covers the error-formatting path which is the only thing this PR changes.