fix(limits): a 4xx made the Codex chip disappear instead of saying why

[pitimon]

Summary

Addresses Part 1 of #105 — the half the issue itself calls the higher-value one.

Verified first, as the issue asks

#105 says "Needs verifying before fixing", so that is what happened. I drove getUsageLimits with a credentialed temp home and a failing fetchImpl across four failure modes (HTTP 500, network unreachable, 401, a body that is not JSON) plus a timeout, and read what each provider actually returned.

The suspicion in the issue is not borne out. It records as unknown "whether every fetcher's failure path actually sets error rather than returning an unconfigured-looking object". It does — every failure path returns { configured: true, error: <message> }, and getUsageLimits wraps each provider in a .catch that does the same.

That is now locked in by tests rather than left as a reading of the source, which is DoD item 2.

One real defect — and it is two issues disagreeing, not a bug

src/lib/usage-limits.js:222 turns a 401/403/404 from wham into { primary_window: null, secondary_window: null }. Its comment says this renders "a neutral empty state instead of a red Fetch failed" — the fix for #52, where users who had not run codex for a week saw an alarming error.

But there was no neutral state to render. LimitChips has exactly two:

if (data.error) { ...status line... }   // visible
...
if (windows.length === 0) return null;  // gone

So on a 401 the chip disappeared — the outcome #105 calls worse than never having had a chip, because the user has been trained to look there and reads absence as "plenty left".

Both issues want the same thing: not red, not gone. The UI just had nowhere to put it.

Added notice as the third state — the same subtle grey line as an error, neutral wording, actionable:

No usage data for this sign-in. Run codex to sign in again.

A provider with genuinely nothing to say still renders nothing; that is kept and tested. What changed is that a failure now always carries either an error or a notice, so it never lands in the empty case.

Scope, stated rather than implied

The tests drive codex, zai, gemini, copilot — the providers a temp home can get past the credential gate. Cursor needs a real install plus a SQLite state DB holding a JWT. Kiro and antigravity gate on a binary and a running process, and returning configured: false when neither exists is correct — nothing broke, so there is nothing to say.

Test plan

• ci:local exit 0 — 932 root tests (+8), 262 dashboard (+4)
• Four failure modes × four reachable providers: all stay configured: true with either an error or a notice
• A timeout is visible, not absent
• A missing credential still hides the chip — the complement, and the reason this cannot just be "always configured"
• A 4xx is a notice, not an error: error is null and the notice is actionable
• Four component tests for the three chip states, including that "no error, no windows, no notice" still renders nothing
• A test pins limitDisplay.jsx's own rule — without it every assertion here could be testing a property the UI no longer has, and would keep passing while the chip regressed

Methodology correction worth recording

The first probe passed an async throwing commandRunner, which is not spawnSync's contract — it returns { error, status, stdout }. That produced a crash that looked like a product defect and was not one. The committed test uses the real contract. Reported here rather than quietly dropped, because "I found a crash" would have been a false finding.

Not in this PR

Part 2 — sanitized response fixtures per provider. Those need real responses to sanitize, which I do not have; the issue notes they contain account identifiers and plan details and must be treated as public once committed. Left open.