Support changing a running Clock's timezone via a seeded successor #11

Summary

The Clock timezone is immutable by design (#8). But a real consumer (e.g. a device whose user changes the timezone setting) wants to carry the in-flight fake time and ongoing distortions into a new zone. new Clock(...) can't do this — it resets the run anchor and accrued offset.

Motivation

"Change device timezone, keep everything running" is a legitimate scenario; today it forces a hard reset.

Proposed direction

• Make the run anchor and starting offset injectable (optional construction params), so you can spawn a successor Clock seeded with the predecessor's _runAnchor, frozen _offset, and _lastCheck, applying the new zone going forward. Past distortion stays locked; elapsed/absolute windows and fake time rebase cleanly.
• Define a time-of-day refire policy for the boundary: when local time jumps, a one-shot window can be re-encountered or skipped — pick "already-spent windows don't refire" vs "re-resolve in the new zone."

Out of scope / open questions

• Whether to expose this as a Clock.rebase({ timeZone }) factory or raw injectable state.
• The refire policy is the genuinely ambiguous part and may warrant its own discussion.