Offer Search again only where the photo backfill runs (Maestro 7a468d2d, review F1/F2)

F1: every dinner response now carries photo_backfill_eligible, computed
by the exported dinners.PhotoBackfillEligible: the condition
ListPhotoBackfillDinners lists by and GroundFailedDinner and
RefailDinnerGrounding write under (unarchived, failed, no photo, no
pasted recipe_url). A test holds the flag to ListPhotoBackfillDinners
for an eligible dinner and for grounded, linked and archived ones. The
fix-recipe sheet shows "Search again" only when the flag is set, so a
dinner with a pasted link is never offered it, whatever its reason.

F2: a dinner absent from the backfill result now reads "This dinner was
not included in that search." instead of claiming a pasted link.

Task: 7a468d2d-4a9b-45f2-b626-a7bed5f671df

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

docs/ARCHITECTURE.md

@@ -276,12 +276,9 @@ automatic** (D-021).
   `grounded`, `failed` (with its reason) or `skipped`. A dinner whose write
   fails is `failed` with `grounding_error` and left as it was; the others
   still run, then the job fails with `internal_error`, keeping that result.
-  The responses returning a `dinners.Dinner` representation (the list; the
-  create, update, archive, favorite and grounding responses; the idea
-  responses) carry `photo_backfill_eligible`, and
-  `GET /api/v1/dinners/{id}` does not; it says whether the backfill grounds
-  that dinner, computed by the same condition it lists dinners by, so a
-  client offers a search only where one runs.
+  Every dinner response carries `photo_backfill_eligible`, whether the
+  backfill grounds that dinner, computed by the same condition it lists
+  dinners by, so a client offers a search only where one runs.
   `GET /api/v1/dinners/{id}/recipe-candidates`
   searches for the dinner's name and returns `{candidates: [{candidate_id,
   title, site_name, photo_url, minutes}]}`, at most 3, ranked as `Ground`