Fix review findings R1–R3 on Regular grounding and name folding

R1: Migration 0010 now writes revision 0 into every ground_dinner job
payload that has none. Jobs queued before the upgrade carry only
dinner_id, so the boot cleanup, which matches a pending dinner to its job
by revision, failed those dinners as interrupted while their jobs were
still queued. The migration runs before the job runner starts. A new test
migrates a database to 0009, adds a pending Regular with a legacy queued
job, upgrades and boots, and checks the dinner stays pending and is then
grounded.

R2: Archiving a dinner, or renaming a pending one, now cancels the
grounding of any ground_dinner job running for it at an older revision,
so no further search, page fetch, photo download or model call is made.
The job is registered before it reads the dinner, so an archive or rename
committed after that read always finds it. A stopped job succeeds and
reports the dinner's current grounding status. The archive and rename
tests now check that the job ends while its search is still held, with
no page fetched and no model call for the stale name.

R3: gen_folds.py writes web/src/dinners/letterFolds.json from the same
table as folds_table.go, and names.ts folds through it instead of a
hand-copied subset. names.ts also lowercases letter by letter, as Go's
strings.ToLower does, rather than by context. TestLetterFoldsMatchPWA
fails when the two tables differ. The shared cases add "Ƈhili", "Ꞔarbanzo
Stew" and "ΜΟΥΣΑΚΑΣ" (final sigma).

Maestro task 5037ff86-181d-448e-927b-c2fd2258a25d.

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

docs/ARCHITECTURE.md

@@ -219,7 +219,10 @@ automatic** (D-021).
   A job for a dinner archived, no longer `pending` or at another revision
   does no work, and a job only writes a dinner still unarchived, `pending`
   and at its revision, so a fix-up made meanwhile wins and an earlier job
-  for an old name — queued or running — never decides the outcome. A
+  for an old name — queued or running — never decides the outcome.
+  Archiving or renaming a dinner also stops its running job where it is,
+  so no further search, page fetch, photo download or model call is made
+  for it. A
   method, minutes_total or difficulty a member saved while the dinner was
   `pending` is kept; grounding fills only those left empty. At boot, after
   the job runner fails the jobs a previous process left running, every
@@ -502,7 +505,9 @@ steps: the welcome (`/onboarding`), the Regulars (`/onboarding/regulars`,
 mock 1h, adding and archiving through the dinners API optimistically; Next
 waits for three saved Regulars, and a common pick is not offered once a
 Regular has a name `harness.Similar` to it — the PWA's copy of the name
-rules in `web/src/dinners/names.ts` runs the same cases,
+rules in `web/src/dinners/names.ts` folds letters with
+`web/src/dinners/letterFolds.json`, which `gen_folds.py` writes from the
+same table as the server's, and runs the same cases,
 `internal/ai/harness/testdata/dedupe_cases.json`, as the server's) and
 notifications (`/onboarding/notifications`: what MealQuest notifies about,
 the iOS install hint, "Turn on notifications" and "Maybe later"). Either