Restore local-time reset clock on the reset readout

[gvonness-apolitical]

What

Brings back the absolute local-time reset indicator that the Python status line had and the Rust port dropped. The reset readout now shows both the time-to-reset and the local clock it lands at, on the status line and in report:

5h  ▕████████▎          ▏ 25%  53m @ 1:59pm (Thu)   ↑30%/h
wk  ▕███                ▏  9%  6d3h @ 5:05pm (Wed)   ↑2%/h  ⚠ cap 1d21h

How

Rust's standard library has no timezone support — SystemTime only yields a UTC epoch and std can't resolve the local offset or DST. A new localtime module converts the UTC reset epoch to local hour/minute/weekday by calling the C library's reentrant localtime_r (unix) / _localtime64_s (Windows UCRT), which read the OS timezone database. This is the same mechanism Python's datetime.fromtimestamp uses under the hood, so it's a faithful restore.

• No new dependency — uses the always-linked C runtime; binary stays ~430KB, serde-only.
• DST/zone-correct, including the weekly reset landing across a DST transition.
• Graceful fallback — if local time can't be resolved, the readout shows the bare duration as before.
• fmt_clock_parts is a pure function with unit tests covering the midnight/noon/am-pm/weekday boundaries.

Verification

• cargo fmt --check, cargo clippy -D warnings, cargo test all pass (17 tests, incl. new clock_parts).
• Verified live: at 1:05pm Thu, a 54-min 5h reset renders 53m @ 1:59pm (Thu) and a 6d3h weekly reset renders @ 5:05pm (Wed) — both correct local times.
• The unsafe FFI was reviewed against all six 64-bit release targets (struct tm layout, time_t width, symbol/arg order, MaybeUninit soundness, reentrancy) — no soundness or correctness issues found.
• README and the demo SVG regenerated to show the clock.