Weekly suggestions schedule (Feature 20) (#172)

Co-authored-by: orchestrator-agent <20+orchestrator-agent@code.cubecraftcreations.com>

docs/ARCHITECTURE.md

@@ -309,20 +309,24 @@ automatic** (D-021).
   `suggest_side_quests` for 5 Side quests (scope: the batch id), then
   grounds the survivors in the model's order with `Grounder.GroundMany`,
   as many as are still wanted at a time, until 5 are kept or none are
-  left. A Side quest no recipe grounds is dropped; each round's grounded
-  ones are stored before the next — a dinner with status `suggested`,
-  origin `side_quest`, grounding_status `grounded` with the recipe's
-  recipe_id, photo_id, method, minutes_total and difficulty and the
-  model's cuisine, and a `pending` suggestion with the name it is
-  suggested under, the reason and `cited_regular_ids` — unless, since the
-  job read its input, a dinner it repeats was added, a suggestion it
-  repeats passed, or a Regular it cites renamed or archived (checked in
-  the storing transaction). The job publishes
-  `{batch_id, stage, suggestion_ids, dropped}` as it goes (`suggesting`,
+  left. A Side quest no recipe grounds is dropped. A `replenish` batch
+  stores each round's grounded ones before the next; a `scheduled` or
+  `manual` batch, which notifies, holds them and stores them all in one
+  transaction once its last round is done. Each is stored as a dinner
+  with status `suggested`, origin `side_quest`, grounding_status
+  `grounded` with the recipe's recipe_id, photo_id, method,
+  minutes_total and difficulty and the model's cuisine, and a `pending`
+  suggestion with the name it is suggested under, the reason and
+  `cited_regular_ids` — unless, since the job read its input, a dinner
+  it repeats was added, a suggestion it repeats passed, or a Regular it
+  cites renamed or archived (checked in the storing transaction). The job
+  publishes `{batch_id, stage, suggestion_ids, dropped}` as it goes (`suggesting`,
   `grounding`, `done`). It fails with `no_regulars`, `ai_failed` (the
   skill or `normalize_recipe` failed; no Side quest is made up instead,
   D-017), `search_not_configured` or `search_failed`, and the batch is set
-  `failed`; Side quests stored before the failure stay in the deck. If
+  `failed`. A failed `scheduled` or `manual` batch has stored nothing; a
+  failed `replenish` batch's Side quests stored before the failure stay
+  in the deck. If
   recording the batch's end fails, its job fails; the job runner retries
   a job's final status write with backoff until it lands, each attempt
   bounded at 5 seconds; at shutdown an attempt that fails or times out is
@@ -775,7 +779,7 @@ purge are fixed and not configurable.
 
 | Schedule | When | Does |
 | --- | --- | --- |
-| `suggestions_weekly` | Sunday 08:00 | New batch of Side quests. |
+| `suggestions_weekly` | Sunday 08:00 | New batch of Side quests (`suggest.Service.WeeklySchedule`). |
 | `plan_draft` | Friday 09:00 | AI drafts next week's plan. |
 | `shopping_chat_autosend` | Saturday 08:00 | Sends the Supply run to Google Chat. |
 | `day_of_reminder` | Daily 16:30 | Tonight's dinner reminder. |
@@ -803,6 +807,16 @@ claimed without running (logged as missed) so it never runs later. DST
 follows `household.LocalTime`: a skipped time fires later by the gap, a
 repeated time fires once, at its first occurrence.
 
+Each schedule is built by the service that does its work, as a
+`scheduler.Schedule` value, and registered in `cmd/server` before the
+scheduler starts: `suggest.Service.WeeklySchedule()` is `suggestions_weekly`.
+Its run calls `StartScheduledBatch(period.Week)`, which starts the same
+batch and job as `POST /api/v1/suggestions/batches` (`StartBatch(manual)`),
+with the `scheduled` trigger, and returns at once; the batch runs as a job. When a
+batch is already pending or running the period starts none and logs it.
+Fake-clock tests of a schedule live in `internal/scheduler`, where
+`SetClock` is visible to tests.
+
 ## Notifications
 
 - Events: `plan_ready`, `list_ready`, `day_of_reminder`, `new_suggestions`,
@@ -820,12 +834,19 @@ repeated time fires once, at its first occurrence.
   - `list_ready:{weekStart}` (URL `/plan/shopping`) when a week's Supply
     run is first created, by `POST /shopping/{weekStart}/generate` or
     after Push to Calendar; remaking it does not notify.
-  - `new_suggestions:{batchId}` (URL `/discover`) when a `scheduled` or
-    `manual` suggestion batch first adds Side quests to the deck, in the
-    transaction storing them, so they are announced even when a later
-    round or recording the batch's end fails; it names that round's Side
-    quests, and a later round's emit stores nothing. A `replenish` batch
-    never notifies.
+  - `new_suggestions:{YYYY-Www}` for a `scheduled` batch, the ISO week it
+    was scheduled for (carried in its job, so a batch caught up late is
+    still keyed by its own week), or `new_suggestions:{batchId}` for a
+    `manual` one (URL `/discover`), once, when the batch's last round is
+    done, in the one transaction that stores all its Side quests, so they
+    and their notification commit together or not at all. Its title
+    counts every Side quest the batch stored ("5 new Side quests are in")
+    and its body names them. A batch that fails at any round, as when
+    `suggest_side_quests` or a later round's `normalize_recipe` fails (the
+    failure is in `ai_runs`), stores no Side quest and sends nothing, so
+    no stored Side quest goes unannounced. A `replenish` batch never
+    notifies. This is the only place `new_suggestions` is emitted; the
+    `suggestions_weekly` schedule does not emit it itself.
   - `day_of_reminder:{date}` (URL `/dinner/{id}`) through
     `plan.Service.EmitDayOfReminder(date)`, which names the dinner planned
     on the date and emits nothing for a week with no plan. The scheduler