docs(notifications): why the reminder backfill counts days in UTC

The backfill in Migration20200101042100 marks reminders as sent by UTC
date('now'), while the reworked job counts days in the app TZ, which read
like a seam that sends twice or skips on upgrade day. It is not: the
backfill stands in for the job before it, which matched start_date
against UTC date('now') at 9 AM app time, so UTC is the clock those
reminders went out by, and with one run per UTC day nothing it marks
was left unsent. The only effect is its strict "<": the upgrade day's
own reminders stay unmarked because the boot may precede that day's
run, so a boot after it reminds such a trip once more. One extra
reminder at most and never a lost one, so the shipped migration stays
untouched and the reasoning now sits on the job.

The todo claim's docstring writes its dedup bound as SQL.

server/src/db/repositories/TodoItems.repository.ts

@@ -245,7 +245,7 @@ export class TodoItemsRepository extends TrekRepository<TodoItems> {
   /**
    * RJ5 (`reminder-jobs.service.ts#todoTick`, looped): claims the reminder
    * before it is sent. `UPDATE todo_items SET reminded_at = CURRENT_TIMESTAMP
-   * WHERE id = ? AND (reminded_at IS NULL OR reminded_at <= now - 20 h)`, the
+   * WHERE id = ? AND (reminded_at IS NULL OR reminded_at <= datetime(now, -20 hours))`, the
    * same dedup bound {@link listDueForReminder} selects by, so of two
    * processes running the tick only the one whose update lands sends. True
    * when this caller holds the claim.