ACP: expose managed account quota (5h / weekly) on usage frames

Problem

Subscription quota (5-hour window, weekly limit, reset times, booster balance) is only visible in the TUI (/usage). ACP clients have no way to show it, so a user running an agent from an IDE/client cannot tell they are about to hit the 5-hour cap until turns start failing with 429.

Related: #2157 (machine-readable quota channel), #1855 (token usage over ACP), #872 (quota in status line).

Proposal

The data already flows through packages/oauth (fetchManagedUsage → /usages) and the SDK auth facade (getManagedUsage). Emit it over ACP attached to the standard usage_update frame as _meta.kimiCode.rateLimits:

{
  "sessionUpdate": "usage_update",
  "used": 182344,
  "size": 1048576,
  "_meta": {
    "kimiCode": {
      "rateLimits": {
        "summary": { "window": "1w", "used": 35, "limit": 100, "resetAt": "2026-08-06T13:38:24Z" },
        "limits": [{ "window": "5h", "used": 35, "limit": 100, "resetAt": "2026-07-31T14:38:24Z" }],
        "booster": { "balanceCents": 500, "totalCents": 1000, "currency": "USD" }
      }
    }
  }
}

Same extension pattern claude-agent-acp uses (_meta["_claude/rateLimit"]), so the convention has precedent in the ecosystem. Fetch is rate-limited to once a minute and best-effort (never blocks a turn). Emitted after every turn and on session open.

Implemented in my fork together with the usage_update emission itself (#1855 covers the base frame); can open a PR.

Start by tracing packages/oauth fetchManagedUsage through /usages and the SDK auth facade's getManagedUsage, then locate the existing ACP usage_update emission. Check how session open and post-turn updates are handled, and compare the proposed _meta.kimiCode.rateLimits shape with the stated one-minute, best-effort behavior. Done means ACP clients receive quota data without blocking turns.