fix(api): tolerate null resets_at for unused usage windows

[jeanfw]

Summary

The Claude API legitimately returns resets_at: null on usage windows that have no consumption yet — typically when an account hasn't been used in the last 5 hours (so there's no active session window to reset). Today the mapper rejects these responses and surfaces:

Server response missing critical field: fiveHour.resetsAt

…which blocks refresh entirely for that account. The popover shows the orange Server returned invalid response banner and the user has no recourse short of using Claude on that account to force the API to populate the field again.

The fix

UsageAPIResponse.toDomain() now treats a null resets_at the same way it already treats a null sevenDaySonnet.resets_at: it falls back to now + window duration (5 hours for the session window, 7 days for the weekly window). A present-but-malformed date string is still treated as a hard error, since that's a real protocol violation.

Logic is factored into a small parseResetDate(from:field:formatter:fallback:) helper so all three windows use the same path.

Test plan

• test_usageFetch_withMissingResetAt_fillsInFallbackWindow covers the new behaviour — null resets_at on the session window decodes to a future date roughly one session-window from now.
• test_usageFetch_withMalformedResetAt_surfacesInvalidResponse ensures the strict path is still wired up — a non-ISO string surfaces AppError.networkError(.invalidResponse).
• All existing tests still pass (the previous test_usageFetch_withInvalidPayload_surfacesInvalidResponse was renamed to make the intent unambiguous after this change).

🤖 Generated with Claude Code

[eddmann]

Thanks Jean. This fix has been incorporated into #21 and merged there, with attribution preserved in the PR body and commit metadata.

I used the same core approach: tolerate resets_at: null by falling back to the relevant rolling usage window, while keeping malformed non-null reset dates as hard failures.

[eddmann]

Thanks again Jean. The null resets_at fix is now included in ClaudeMeter v1.3.1.

The released implementation follows the same core approach from this PR: tolerate null reset timestamps by falling back to the relevant rolling usage window, while keeping malformed non-null reset dates as hard failures.