Merge task/476 into the entity-reference branch (V-524)

--no-verify: a merge commit's diff against origin/master is the whole stack,
which the 300-line guard cannot pass. The one conflict was in
internal/store/migrations.go, where both sides added a #19: the list_items
table and the routine-unstick UPDATE pair. Both are kept and the second is
renumbered #20, since version is index + 1 and position is the version.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XGTGCWX33aX8SMBSRz9VmS

internal/store/migrations.go

@@ -240,6 +240,35 @@ ALTER TABLE reminders ADD COLUMN next_fire_ts INTEGER;`, // #2
 	// The live-only unique index is the tasks one, per list: saying "молоко"
 	// twice before the shop keeps one row, saying it again next week after the
 	// last one was crossed off writes a new one.
+
+	// #20 — 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