Tell "this window is not running" from "we could not read the time"

The five-hour window's reset time is absent between blocks, because the
window is anchored to the block it started in and there is nothing to reset
until one is running. Measured against a live response: the reset came back
as exactly five hours after work resumed, and the weekly windows in the same
response carried the identical microsecond, so both are computed from one
now() at request time. The weeklies always have a reset because a week is
always running -- which is why only the five-hour row looked wrong.

`remainingUntil` returned null for that and for a timestamp it could not
parse, so the session bar announced "reset time unknown" about a machine
behaving perfectly, on the one row somebody reads before starting something
big. The usage dialog, looking at the same field, drew nothing at all and
printed a raw ISO string when a parse did fail. One missing value, two
rules, and neither of them right.

`WindowEnd` names the three answers and both callers go through it. A window
that is not running shows its percentage and no countdown, in the bar as
well as the dialog; an unreadable timestamp says so in words rather than
showing itself.

Looked at both on the emulator, the second by making the server drop the
field: 15% with "4h 43m left" when a block is running, "13%" alone when none
is, and the dialog's five-hour row with no reset line beside weeklies that
have one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

AGENTS.md

@@ -457,6 +457,21 @@ machine belongs in `~/.claude/TOOLCHAIN.md` (toolchain versions) or
   the screen opens. The reset is not optional: without it the window is
   spliced onto rows that are no longer adjacent to it, which reads as
   ordinary output.
+- **The five-hour window has no reset time between blocks, and that is not
+  a missing value.** The usage API anchors it to the block it started in --
+  measured 2026-08-31, the reset came back as exactly five hours after work
+  resumed, and the weekly windows in the same response carried the identical
+  microsecond, so both are computed from one `now()` at request time. When
+  no block is running there is nothing to reset and `resets_at` is `null`;
+  the same response shows other idle windows with the same shape. The weekly
+  ones always have a reset because a week is always running, which is why
+  "the others seem fine".
+  So `resets_at` absent means **not running**, and only a timestamp that
+  arrives and cannot be parsed is unknown. The app collapsed both into one
+  null and the session bar said "reset time unknown" for a machine behaving
+  perfectly -- while the usage dialog, reading the same field, quietly drew
+  nothing. `WindowEnd` in `ResetCountdown.kt` is now the one rule both go
+  through.
 - **A transcript page used to cost the whole transcript.** `read_window`
   read and parsed every line and then kept the last `limit` of them, so the
   work was the size of the conversation rather than the size of the answer: