feat(autotheme): fire at the configured sunrise/sunset, not a 15-min poll

The timer's OnCalendar now bakes the configured times (falling back
like _hhmm_to_min on a hand-edited state), so the switch lands at the
configured minute instead of up to 15 minutes late. The original
poll's robustness case is covered without it: Persistent catches
transitions missed while powered off, systemd fires elapsed calendar
timers on resume, and OnStartupSec settles the theme after login.

Baked times mean a time edit must rebuild: the menu's Sunrise/Sunset
writes now run `auto --force` when enabled (one rebuild re-bakes the
timer and lands on the right theme, same as the enable flow). Day and
night slugs stay live reads — but with no poll to catch them up,
editing the slot currently on screen applies immediately via a plain
`auto`. New eval check `auto-theme-timer` asserts the bake
state-bridges-style: configured times reach OnCalendar, garbage falls
back to 07:00/20:00, disabled installs no unit. Docs + hardware-queue
entry updated to the new semantics.

V2: checks.auto-theme (KVM VM, passed) covers the auto engine the
timer ticks; checks.auto-theme-timer (eval, passed) covers the unit;
OnCalendar strings systemd-analyze-validated; the rebuilt menu script
passes bash -n with the new branches in place. V3 pending: live timer
firing at the exact configured minute on hardware (existing
"Auto-theme pair flip" queue entry, refreshed).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/ROADMAP.md

@@ -316,11 +316,17 @@ Design/decision records and a running log of shipped work (items marked
   drives `nomarchy-state-sync auto`, which picks day vs night by the local
   clock and applies the preset **only if it differs** (idempotent).
   `modules/home/autotheme.nix` installs a user timer
-  (`OnStartupSec` + `OnCalendar=*:0/15` + `Persistent`, gated on the state
+  (`OnStartupSec` + `OnCalendar` + `Persistent`, gated on the state
   flag) that ticks `auto`; Look & Feel › Auto theme toggles it and picks the
   pair/times. `cmd_apply`'s core was factored into `apply_named` so `auto`
-  reuses it verbatim. Periodic (not exact sunrise/sunset timers) for
-  robustness to suspend/DST; the idempotent `auto` keeps ticks cheap. Enable
+  reuses it verbatim. Originally a 15-min poll (`OnCalendar=*:0/15`) for
+  robustness to suspend/DST; **revised** (Bernardo 2026-07-18) to fire
+  exactly at the configured sunrise/sunset — `Persistent` covers powered-off
+  gaps, systemd fires elapsed calendar timers on resume, and `OnStartupSec`
+  settles login, so the poll bought nothing but a ≤15-min switch lag. The
+  times are now baked into `OnCalendar`, so the menu's Sunrise/Sunset edits
+  rebuild via `auto --force` (day/night slugs stay live reads; editing the
+  on-screen slot applies immediately since no poll catches it up). Enable
   rebuilds once (installs the timer + `auto --force`); disable is instant
   (the flag flips and `auto` self-gates). **V2:** `checks.auto-theme` moves
   the VM clock across a configured sunset/sunrise and asserts the theme flips