fix(alarms): re-arm a skip when the pause changes, and clear spent dates in place

A skip armed under one pause kept its watermark when the pause changed,
so removing the pause left the alarm silent until the old pause's end.
The engine now re-arms a pending skip after a pause edit.

Spent dates and pauses are cleared with targeted, conditional updates
instead of a whole-row rewrite. SET_ALARM ignores a date or pause that
has already gone by when looking for an alarm to re-use, the editor
re-reads the clock when a date picker opens, and the next-alarm widget
shows the year for a date in another year.

docs/ARCHITECTURE.md

@@ -1326,9 +1326,14 @@ single candidate, so clearing it changes nothing but the row. Measuring from
 midnight would otherwise be cleared at 00:00 and let its last day's 23:59
 occurrence ring late through the grace window. The resolver reports
 `clearScheduledDate` / `clearPause` on every branch, a disabled alarm included,
-and the engine writes them through `AlarmRepository.edit`, conditional on the
+and the engine writes them as column-targeted `UPDATE`s conditional on the
 stored value still being the one it resolved, so a pause the editor has just
-picked is never cleared by a resolution of the old one.
+picked is never cleared by a resolution of the old one, and no other column is
+rewritten. Changing a pause calls `AlarmEngine.onPauseChanged`, which drops a
+skip watermark still in the future so the resolver re-arms it on the new
+sequence: removing a pause must not leave the skip on the first ring after the
+old one, and adding a pause over the skipped day must not spend the skip on a
+day already silent.
 
 The surfaces never show a stale one in the meantime: `AlarmSchedule` shows a
 date only while its occurrence is still ahead and a pause only while its last