nudges: a resolved outcome and a way to close a pending alarm (V-535)

The sev4 repeat path reads the nudges table, so ending an alarm means
writing an ending there. 'resolved' is the daemon closing it because the
condition cleared, which is neither 'acted' nor 'ignored'.

ResolvePendingTelegram is rule-scoped and accepts only the two endings the
daemon may write. OldestPendingTelegram backs the age cap and scans into a
NullInt64, because MIN over an empty set is one NULL row, not zero rows.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

internal/store/migrations.go

@@ -269,6 +269,27 @@ ALTER TABLE reminders ADD COLUMN next_fire_ts INTEGER;`, // #2
 	UPDATE proposed_routines
 	     SET accepted_ts = created_ts, reminder_id = NULL
 	   WHERE status = 'accepted' AND accepted_ts IS NULL;`,
+
+	// #21 — allow 'resolved' as a nudge outcome (Vikunja #535). The sev4 repeat
+	// path needs an ending that means "the condition cleared, so I stopped
+	// talking", which is neither 'acted' (he answered) nor 'ignored' (nobody
+	// ever did). A CHECK cannot be altered in place, so the table is rebuilt.
+	// Rows carry over unchanged; only the constraint widens.
+	`CREATE TABLE nudges_new (
+	   id          INTEGER PRIMARY KEY AUTOINCREMENT,
+	   ts          INTEGER NOT NULL,
+	   rule        TEXT    NOT NULL,
+	   channel     TEXT    NOT NULL,
+	   message     TEXT    NOT NULL,
+	   outcome     TEXT    NOT NULL DEFAULT 'pending' CHECK (outcome IN ('pending','acted','snoozed','ignored','resolved')),
+	   outcome_ts  INTEGER
+	 );
+	 INSERT INTO nudges_new (id, ts, rule, channel, message, outcome, outcome_ts)
+	   SELECT id, ts, rule, channel, message, outcome, outcome_ts FROM nudges;
+	 DROP TABLE nudges;
+	 ALTER TABLE nudges_new RENAME TO nudges;
+	 CREATE INDEX IF NOT EXISTS idx_nudges_rule_ts ON nudges (rule, ts DESC);
+	 CREATE INDEX IF NOT EXISTS idx_nudges_outcome ON nudges (outcome);`,
 }
 
 // migrate applies every migration with a number greater than the DB's current