store: wake the routines accepted before the fire-forever fix (V-377)

Routines accepted before Vikunja #366 carry accepted_ts NULL and a live
reminder row. The tick loop reads accepted_ts to decide when a routine is
next due, so those rows have been silent since the fix landed, while the
reminder they still point at keeps firing on its own schedule.

Migration #19 cancels that reminder first, then dates the acceptance from
created_ts and lets the reminder id go. Order matters: the second update
clears the id the first one needs.

internal/store/migrations.go

@@ -219,6 +219,35 @@ ALTER TABLE reminders ADD COLUMN next_fire_ts INTEGER;`, // #2
 	// event, and the old rows would otherwise be recited as extra meetings.
 	// The filter is exact — it keeps any key whose summary part still has a
 	// letter or a digit in it.
+
+	// #19 — unstick the routines accepted before the fire-forever fix
+	// (Vikunja #377, follow-up to #366). Accepting used to leave accepted_ts
+	// NULL and a live one-shot reminder behind, and the tick loop skips a row
+	// with no accepted_ts, so every non-weekly routine accepted before that fix
+	// has been silent ever since.
+	//
+	// Three statements, in this order, per stuck row: adopt created_ts as the
+	// acceptance time, cancel the reminder that is still holding the schedule,
+	// then let go of it. Cancelling before clearing matters — clearing first
+	// loses the only pointer to the reminder and leaves it to fire on its own.
+	//
+	// created_ts rather than a fresh timestamp because a migration has no
+	// clock, and because the first interval should be measured from when he
+	// said yes. A routine whose interval has already elapsed nudges on the next
+	// tick, which is what being unstuck looks like.
+	//
+	// Weekly rows are included deliberately. Theirs was the case that kept
+	// working, because the cron reminder reschedules itself — so leaving them
+	// alone would give them both a cron reminder and a tick-loop schedule for
+	// one habit, and he would hear it twice.
+	`UPDATE reminders
+	     SET status = 'cancelled'
+	   WHERE status = 'pending'
+	     AND id IN (SELECT reminder_id FROM proposed_routines
+	                 WHERE status = 'accepted' AND accepted_ts IS NULL AND reminder_id IS NOT NULL);
+	UPDATE proposed_routines
+	     SET accepted_ts = created_ts, reminder_id = NULL
+	   WHERE status = 'accepted' AND accepted_ts IS NULL;`,
 }
 
 // migrate applies every migration with a number greater than the DB's current