fix: stop rescaling Claude utilization below 1% to 100%

[yozu]

Problem

A Claude session at 1% is displayed as 100% used, with the red "used up" state, while the Claude settings page reports 1% for the same window.

normalize_utilization (duplicated in the OAuth and web API fetchers) treats any utilization value in (0, 1] as a fraction and multiplies it by 100:

fn normalize_utilization(utilization: f64) -> f64 {
    if utilization > 0.0 && utilization <= 1.0 {
        utilization * 100.0
    } else {
        utilization
    }
}

The API already reports these values in percent units, so every window at or below 1% is inflated by 100x. Values above 1 are unaffected, which is why the bug only shows up on freshly reset windows.

Why percent is the right unit

• scoped_weekly::weekly_all_window already consumes the sibling limits[].percent field as-is, without rescaling.
• The payload captured in the existing weekly_all_limit_wins_over_stale_seven_day_utilization test carries "seven_day": {"utilization": 1.0} next to "kind": "weekly_all", "percent": 1.0 — the same window, the same value, in both fields.
• That test already asserts the weekly window must be 1%, not 100%. The limits[] path satisfied it; to_rate_window did not.

Change

Remove normalize_utilization from both fetchers and use utilization directly. This covers the five-hour session, seven-day, model-scoped (Opus/Sonnet), OAuth apps and Daily Routines windows.

Tests

• Renamed converts_fractional_utilization_to_percent to keeps_sub_one_utilization_in_percent_units in both modules and flipped the expectation (0.23 stays 0.23).
• Added one_percent_session_is_not_reported_as_full_quota covering the reported symptom directly.
• Updated parses_current_snake_case_oauth_usage_response, which encoded the old behaviour (1.0 -> 100.0, 0.14 -> 14.0).
• cargo test: 1207 passed, 0 failed. cargo clippy --all-targets: no new warnings.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[Finesssee]

Thanks for the PR, I will review this ASAP.

[Finesssee]

Requesting changes — this is a structural block, not a behavioral one. The fix itself is correct and validated.

The utilization reading is right: 1.0 means 1%, and the old duplicated normalize_utilization rescaling in both fetchers reported a sub-1% session as a fully consumed quota. Dropping it in favor of reading window.utilization directly, renaming the tests to keeps_sub_one_utilization_in_percent_units, and adding the one_percent_session_is_not_reported_as_full_quota regression test pins the actual failure mode.

Blocking: rust/src/providers/claude/oauth/mod.rs crosses the repo's ~1000-line file-size bar in this PR (999 → 1011). The inline #[cfg(test)] mod tests occupies lines 621–1011 — roughly 390 lines, over a third of the file — and that is exactly the growth pattern the threshold exists to catch. Before merge: extract the inline tests into rust/src/providers/claude/oauth/tests.rs (behind a mod tests; include in mod.rs), which brings mod.rs back under the bar without touching behavior.

Non-blocking follow-up: the OAuth and web fetchers still each convert provider windows into UsageWindow with duplicated percent-units semantics. That conversion should become one canonical converter shared by both paths. If the two conversions stay separate, mirror the exact 1.0 → 1% assertion in web_api.rs as well — its tests currently cover 0.23 → 0.23 and 23.0 → 23.0 but not the boundary value that caused this bug.

The scope of this request is the threshold crossing; the fix logic itself does not need to change.