v0.3.7 — per-provider utc_offset for zone-less reset times

What changed

429 error messages often state when the quota resets, and many upstreams
write that instant in their own local time with no zone marker. Zhipu's
production shape:

{"code":"1310","message":"您已达到每周/每月使用上限，您的限额将在 2026-11-10 22:58:54 重置。"}

22:58:54 is Beijing time, but the body scan read it as UTC and force-opened
the provider until 2026-11-11 06:58:54Z — eight hours after the real reset,
so a healthy channel stayed walled off all morning.

Providers now take an optional offset that is applied only to zone-less
timestamps in that provider's own error text:

[providers.one_api_zhipu_1]
utc_offset = "+08:00"   # also +0800 / +08 / -05:30 / Z

Anything that carries its own offset (Retry-After, x-ratelimit-reset-*,
+0800, Z, RFC 3339) is unaffected — the config is an assumption for the
ambiguous case, never an override. Unset keeps the previous UTC reading; an
invalid value is rejected at config load:

provider 'mock' has invalid utc_offset 'Asia/Shanghai' (expected e.g. "+08:00", "+0800" or "Z")

Verification

Check	Result
cargo fmt --all -- --check	clean
cargo clippy --workspace --all-targets -D warnings	clean
cargo test --workspace	668 passed, 0 failed (4 ignored)
cargo test --test integration ×5	105/105 each run
Release binary --version	maxllm 0.3.7
Release binary starts with utc_offset = "+08:00", /health	{"status":"ok"}

End-to-end proof in the integration suite: the same zone-less message leaves
the breaker closed (maxllm_circuit_breaker_state = 0) when
utc_offset = "+08:00" makes the instant already past, and force-opens it
(= 1) without the offset because it reads as 7 h ahead.

Asset

maxllm-server-linux-x86_64-musl — static-pie, sha256
e6d41f3033babd8c0e31e6e102c764977c7a507ac488cfcab4171cfc378b214f