fix(alarms): keep the alarm-set notice until a screen has shown it

The usual way to set an alarm is pick, OK, back, and back disposed the
editor's snackbar a moment after it appeared. Day taps left within the
one-second settle were never announced at all, and a rotation threw a
showing snackbar away for good.

The announcer is now an app-wide singleton holding the notice as state
until a snackbar has run to the end, so the list picks up what the
editor could not finish showing. An editor closed mid-settle announces
on the way out. Announcing is serialised, so a quick on-then-off cannot
land the "on" read last, and a notice nobody showed within ten seconds
is dropped rather than shown stale. The engine's one-alarm read now
shares upcoming()'s preview helper.

Refs #19

docs/ARCHITECTURE.md

@@ -1123,7 +1123,11 @@ only a natural occurrence of an enabled alarm, rounded as the row's countdown
 is, never a snooze or a ring. The `AlarmClock` intents never reach it, since
 they already get the status-bar icon (#19). The editor announces a time pick
 at once, but waits for repeat-day taps to settle for a second, so Mon–Fri is
-one snackbar rather than five.
+one snackbar rather than five. `AlarmSetAnnouncer` is an app-wide singleton
+holding the notice as *state* until a screen has shown it to the end: pick →
+OK → back disposes the editor's snackbar a moment after it appears, and the
+list underneath picks the same notice up. A notice older than ten seconds is
+dropped unshown rather than shown with a stale countdown.
 
 `upcoming(refresh: Flow<Unit>)` takes its **re-read cadence as a parameter**.
 The resolver needs a `now`, and `upcoming` reads one inside a `combine` of the