menubar: surface Codex limit-reset credits (count and next expiry) in the Plan tab

[avs-io]

Closes #723.

What changed

The menubar's Codex Plan tab now shows the limit-reset credits the account is holding: a Limit resets · N available · next expires <relative> row under the quota windows, hidden when the count is zero.

• CodexSubscriptionService gains a companion fetch of GET /backend-api/wham/rate-limit-reset-credits (same bearer token and ChatGPT-Account-Id header as the existing /wham/usage call, plus the OpenAI-Beta: codex-1 gate header, 4s timeout). It is strictly best-effort: any network/HTTP/decode failure yields nil and the Plan view renders exactly as before — this endpoint can never break the quota display.
• parseResetCredits is a small internal parser: takes the server's available_count as authoritative, and derives "next expiry" as the soonest future expires_at among credits with status == "available" (redeemed/unknown-status credits and already-expired timestamps are excluded). ISO-8601 with and without fractional seconds both accepted.
• CodexUsage gains an optional resetCredits field; nothing else about the usage decode changes.

How tested

• swift build clean via a local swift.org 6.3.3 toolchain.
• New CodexResetCreditsTests (10 assertions) cover: full payload picking the soonest available expiry (fractional-seconds timestamp) over an earlier-expiring redeemed credit; missing expires_at; unknown status values; already-expired credits; empty list; malformed document / missing count / negative count → nil.
• XCTest cannot run on this machine (no Xcode; the swift.org toolchain has no XCTest module — this affects the whole existing mac/Tests suite, not just this file), so CI is the test gate here. The parser logic was additionally verified locally by running the identical fixtures through a standalone script under the same toolchain: 10/10 pass.

Not covered: a live end-to-end fetch against chatgpt.com (no test account plumbing in the repo); the endpoint contract matches what the Codex desktop clients use.

[iamtoruk]

Verified locally: swift build green, full run green under both test frameworks, and the parser semantics are mutation-pinned (max-instead-of-min expiry fails a test, dropping the available-status filter fails a test). The lifecycle integration answers the #723 constraint better than I phrased it: fetching inside the usage 200 branch means same single-flight, same cadence, and during a usage 429 block the credits endpoint is never touched at all, so Retry-After is honored transitively. Zero-count hides the row as asked.

One accepted softness, noting for the record rather than blocking: credits ride the usage snapshot, so a credits-only failure on an otherwise successful refresh hides the row instead of showing last-good. Honest omission of an informational row is fine; if users ever report flicker we can add a short-lived carry-over then.