fix(cron): prevent double-fire after timezone offset migration (#28934)

[Jiahui-Gu]

Summary

Fixes #28934. After a Hermes timezone change (e.g. Australia/Sydney → Europe/Berlin), recurring cron jobs whose next_run_at was persisted with the old offset would fire twice the same day: once early (the same UTC instant interpreted in the new tz), then again at the intended wall-clock time after compute_next_run re-advanced it.

Root cause

cron/jobs.py::_get_due_jobs_locked() normalized stored next_run_at via _ensure_aware() which only preserves the absolute UTC instant. A row stored as 2026-05-19T21:00:00+10:00 becomes 2026-05-19T13:00:00+02:00 after migration. At local 13:02+02:00 the scheduler considers it due even though the user's wall-clock intent was 21:00.

Fix

Before treating a recurring next_run_dt <= now as due, compare the persisted offset against _hermes_now().utcoffset(). If they differ and the stored wall-clock time (offset rebased onto current tz) is still in the future, recompute next_run_at in the current tz and skip dispatch this tick. The pre-existing stale-grace fast-forward path is untouched.

Test plan

• New TestTimezoneMigrationDoubleFire in tests/cron/test_jobs.py:
  • Seeds next_run_at=2026-05-19T21:00:00+10:00, monkeypatches _hermes_now to 13:02+02:00
  • Asserts get_due_jobs() == [] (no early fire)
  • Asserts next_run_at is rewritten in current tz to a future instant
  • Asserts a second tick at the same time still does not fire
• pytest tests/cron/test_jobs.py → 80 passed

🤖 Generated with Claude Code

[Jiahui-Gu]

Closing in favor of earlier PRs #28951 / #28985 / #28941 which target the same #28934 timezone double-fire. Three open competing fixes is enough — releasing review bandwidth.