fix(alarms): spend a date on the ring that used it, and harden date input

A dated one-shot whose time was moved later while it was snoozed rang a
second time that day, because closing the cycle only asked whether the
date was still ahead. It now keeps the alarm on only for a date after the
day that rang, and a one-shot switched off as its cycle closes lets its
date go.

The date pickers accept every year a stored date can have, so a far date
from a backup can no longer crash the editor. The widget formats its date
with the list's own formatter, and a backup's leftover date on the wrong
kind of alarm is ignored instead of rejecting the file.

docs/BACKUP.md

@@ -105,7 +105,7 @@ One object per row of `alarms`, config only:
 A date that does not parse, lies outside 2000-01-01..9999-12-31, a pause with
 only one end, or a pause ending before it starts rejects the whole file, like
 an out-of-range `hour`. A date on a repeating alarm or a pause on a one-shot is
-dropped rather than rejected, which is what the editor would do with it.
+ignored unread, valid or not, which is what the editor would do with it.
 
 **Not exported:** the `alarm_states` ring-state table (snooze/ringing/handled-
 occurrence bookkeeping). It is volatile, per-device state, not configuration,