Read the Windows rings the way the Mac does: stale, and round-ended

[RawJat]

Four differences between how a Windows ring reads and how the Mac's does. None of them change what a reading says — only when it is dimmed and how it is drawn.

Stale at 15 minutes, not 5. staleOf dimmed anything fetched more than 5 minutes ago; the Mac's UsageStore.staleAfter is 15, and it polls at 1 and 5. At five minutes a reading dimmed between two polls of a provider that was answering perfectly well, so "stale" came to mean "fetched a little while ago" rather than "old enough not to trust". traymenu::stale_since asked the same question five minutes earlier than the page, though its own comment says both draw on the same rule, so it moves too.

A refused refresh is not a stale reading. usage.rs set status = "stale" on the first 429, though the reading behind it was seconds old — and since the endpoint is the only source Windows has, one 429 dimmed the notch for as long as the rate limit lasted. This is the case that actually bites: I hit it within a minute of testing the change above. The Mac keeps the status it had and lets age decide (UsageStore holds the previous status until staleAfter), and its back-off guards the endpoint rather than the reading. So a 429 now leaves the status alone and says what is happening in the note it already writes — "Rate limited, retrying in Ns" — while the reading ages out on its own fifteen minutes after it was really fetched. A failure for any other reason is treated the same: no reading at all is still an error, a reading we could not refresh is just a reading. A snapshot restored from disk likewise keeps the status it was saved with, since fetched_at came back with it and its age is already known.

Only the reading dims. .dim sat on the whole .ringwrap, so the spinning white arc and the yellow attention pulse faded along with the percentage. Whether an agent is running right now is current whatever the age of the number beside it — the Mac adds its ActivityArc after the opacity it gives the stale stack, and TASKS.md says it outright: "Staleness dimming applies to the usage reading only." The activity arc moves into an SVG layer of its own so the dim goes around it. The track, the weekly ring and the glyph still fade.

Round arc ends. The Mac strokes its rings with lineCap: .round; these were square. A fraction of exactly zero now draws nothing at all, because a zero-length dash paints a dot once the caps are round, where the Mac's trim(from: 0, to: 0) draws nothing.

A reading small enough that its two caps meet still draws as a dot, exactly as it does on the Mac — ProviderRing.sweep is min(max(usedFraction ?? 0, 0), 1), with no minimum. #260 is arguing for a floor on the local model's arc rather than this one, so that question belongs with #260 rather than here; if it lands, the same floor belongs on these rings too.

Testing: cargo test 98 pass, 0 fail, 2 ignored; windows/scripts/check-ui-scripts.mjs parses all three pages. Checked by hand on Windows 11: the arcs read as round-ended, staleness forced on in a throwaway build confirms the rings fade while a running agent's arc stays at full strength, and a rate-limited Claude now keeps its reading with "Rate limited, retrying in Ns" in the card instead of greying out on the first 429.

#257 also touches notch.html and usage.rs. In notch.html it is around the card and the pointer handlers, while this is the ring CSS and renderRing/svgArc. In usage.rs its nearest hunks are at ~471 and ~528 and this one sits between them, in the RateLimited and Other arms — close, but not the same lines.