fix(providers): adapt to Claude 429 edge limits and Codex window schema change

[danielbanariba]

Problem

Both providers stopped reporting usage after independent upstream API changes:

• Codex (chatgpt.com/backend-api/wham/usage) now returns the 7-day window as primary_window (limit_window_seconds: 604800) with secondary_window: null. The positional session/weekly mapping put the weekly figure under "Session" and left "Weekly" dead.
• Claude (api.anthropic.com/api/oauth/usage) now rate-limits at the edge, returning 429 with retry-after ~340s even unauthenticated. Under GJS this surfaced as a hard throw:

  [brainusage] Claude provider threw: 429 is not a valid value for enumeration Status
  

  Soup.Message.get_status() validates its return against the Soup.Status enum, which has no 429 entry, so it throws — the 429 was misclassified as a network error and the rate-limit backoff never engaged. The panel went blank.

Changes

Codex window handling (shared/core/normalize.js, shared/providers/codex.js)

• Classify windows by duration (limit_window_seconds >= 86400 → weekly) instead of position; fall back to positions only for legacy payloads without a duration.
• A single-window payload is now valid (ok) instead of a partial_data failure.
• A missing window yields null → renders -- left, not a misleading 0%.

Claude / GNOME runtime (extension/lib/runtime/fetch.js, shared/core/scheduler.js)

• Read the status_code property instead of get_status(), so unlisted-but-valid HTTP codes (429, 451, …) don't throw.
• Set a 30s Soup session timeout — without it a hung request never settles and the scheduler's per-provider serial queue stays wedged until shell restart.
• Raise the default poll interval 180s → 600s to respect the edge rate limit.

Resilience (shared/core/state.js, shared/ui/render.js)

• Keep the last known usage on failure instead of blanking the panel.
• Add a RATE_LIMITED warning so retained data is clearly labeled as stale rather than mistaken for current.

Testing

bun test — 61 pass, 0 fail (9 files). New/updated coverage:

• normalize.test.js — flipped real payload (7d in primary / null secondary), classic both-windows mapping, legacy positional fallback.
• codex-provider.test.js — single-window ok, no-windows schema_changed.
• state.test.js — last-known data retained on failure.
• scheduler.test.js — 600s interval.
• ui-render.test.js — rate-limited warning alongside retained data.

Verified live against both real APIs (GJS against the actual Soup runtime): Codex weekly reads correctly from the relocated window, and the Claude 429 is now handled as a rate limit with backoff instead of throwing.

Notes / follow-ups (not in this PR)

• KDE kde/shared/code/runtime.js xhrFetch() has no request timeout — same queue-wedge risk exists there, but QML XMLHttpRequest (Qt5 V4 / Qt6) has no timeout/ontimeout, so a QML-side watchdog would be needed. Worth a separate issue.
• classifyCodexWindows() keeps the first window per duration class; if the API ever returns two same-duration windows the second is dropped. No such payload observed.