Usage meter model, governing-meter selection, and reader interface

[Ryan-Atkinson87]

Define the normalised usage model the rest of the monitor reasons over: the set of meters that
apply to the active provider/plan, the snapshot that aggregates them, governing-meter selection,
and the reader interface implementations satisfy.

Spec: §6.1 (Meters), §6.3 (Threshold rule — "most restrictive applicable meter").

Acceptance criteria

• A Meter type with: kind (five_hour, seven_day, seven_day_opus, seven_day_sonnet, agent_sdk_credit, api_budget), utilisation (0–100), resets_at (optional), and limit/used where the source provides them.
• A UsageSnapshot aggregating the meters that apply to the active provider/plan, plus the timestamp of the read.
• Plan → applicable-meter-set mapping (pro / max / api and provider equivalents) so a switch reloads the right set (consumed by Provider/plan switch meter reload and wave-loop monitor integration #37).
• Governing-meter selection returns the meter closest to its limit (most restrictive); ties resolved deterministically.
• Forward-compatible: an unknown/new meter kind appearing in source data is carried through (not dropped, not a crash), per the §6.2 volatility caveat — new meters/weightings must appear without code changes.
• A UsageReader interface (returns a UsageSnapshot; the active path is chosen by plan) that Subscription usage reader: OAuth /api/oauth/usage poll with degradation chain #31 (subscription) and API-mode usage reader from response headers (built, inactive) #32 (API) implement.
• Unit tests cover governing-meter selection, the plan→meter-set mapping, and unknown-meter pass-through.

Builds on the normalised usage type from #16 and the provider.plan config from #4.

Depends on: #16
Depends on: #4