chutes: same ambiguous 0..=1 fraction rescale heuristic as #407 (real 1% becomes 100%)

[Finesssee]

Summary

rust/src/providers/chutes/mod.rs (extract_percent-style key scan) still applies an ambiguous fraction heuristic:

if let Some(v) = map.get(key).and_then(Value::as_f64) {
    return Some(if v <= 1.0 { v * 100.0 } else { v });
}

The same bug class fixed in #247, upstream CodexBar steipete#3216, and #407: when the provider returns whole percentages, a real 1% satisfies v <= 1.0 and is rescaled to a false 100%, which surfaces as an exhausted/misleading quota state. The value 0.5 (a real half percent) is likewise ambiguous against a 0..1 fraction.

Acceptance

• Determine the actual unit contract of the Chutes usage API fields (percent-style keys hit by the key scan at rust/src/providers/chutes/mod.rs).
• If the API returns whole percentages in 0..=100, drop the v <= 1.0 { v * 100.0 } rescale and clamp to 0..=100 directly, mirroring the fix in fix(opencodego): keep API percent in 0..=100 units #407 (rust/src/providers/opencodego/usage_api.rs).
• Add regression tests for 1 (stays 1%), 0.5 (stays 0.5), and 100.
• If some Chutes fields genuinely are fractions, document the split explicitly at the parse site instead of the ambiguous heuristic.

References

• Fix precedent: fix(opencodego): keep API percent in 0..=100 units #407 (OpenCode Go API path)
• Related: [Bug] OpenCode Go: rolling 5-hour usage shows 100% / "Exhausted Weekly" when opencode.ai reports 1% #247, upstream OpenCode Go: weekly usage shows 100% when the true value is 1% (fraction heuristic misreads whole-percent API values) steipete/CodexBar#3216