Require a verified restore point before deploy; mark rotation schedule planned

RUNBOOK: the deploy steps now verify, before the restart that applies
migrations, that Litestream replication is current and its replica
restores to the live data, and record the pre-deploy restore point; if
not, do not restart. The rollback section restores to that recorded point.

ARCHITECTURE: the rotation_check schedule that calls MarkTried is planned
(Feature 20); this release ships MarkTried and the rotation review read and
decide APIs only.

Task: 008c0a8a-2242-429b-a1fd-69346bc1d414

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

docs/ARCHITECTURE.md

@@ -370,9 +370,12 @@ automatic** (D-021).
   plan. A date outside the week is 400 `invalid_date`, an unknown dinner or
   a week with no plan 404, any other dinner 409 `dinner_not_plannable`, and
   a dinner already on another day of the week 409 `dinner_already_planned`.
-- Rotation check (`plan.Service`, D-021). `MarkTried(date)`, which the
-  `rotation_check` schedule calls for the household-local day just past,
-  moves every `quest_log` dinner planned on that date, on a plan of any
+- Rotation check (`plan.Service`, D-021). This release provides the
+  `MarkTried` service method and the rotation review read and decide APIs
+  below. The `rotation_check` schedule that is to call `MarkTried` for the
+  household-local day just past is planned (Feature 20, the scheduler) and
+  not wired yet: nothing in production calls `MarkTried`, so no Rotation
+  check opens automatically. `MarkTried(date)` moves every `quest_log` dinner planned on that date, on a plan of any
   status, to `tried` and opens a `pending` `rotation_reviews` row for it;
   a dinner already checked for that date is left as it is, so it is
   idempotent. `GET /api/v1/rotation-reviews` returns `{reviews}`, the