Redact recipe-candidate failures in logs

A recipe-candidates request whose stored-recipe lookup failed logged the
error unchanged, and that error quotes the search result's URL, which can
carry a personal token, along with the database error text.

dinners.Service.Candidates now wraps every failure other than a missing
dinner in ErrCandidatesFailed, and writeDinnerError logs it as a fixed
reason (candidates_failed) with the dinner id only, answering 500
internal. Not-found, not-configured and search-failed responses are
unchanged.

Fixes MQ-98-06 (Maestro 3759a975-f937-4284-81a2-9e61345a3aa3).

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

docs/ARCHITECTURE.md

@@ -240,7 +240,12 @@ automatic** (D-021).
   (kept in memory, so a restart means fetching the candidates again) at
   the `grounding_revision` it was searched at, so a candidate offered
   before any rename is refused even if the name is changed back; the
-  page's URL, which may carry a token, is never returned or cached.
+  page's URL, which may carry a token, is never returned or cached. An
+  unknown dinner is 404, recipe search not set up 409 `not_configured` and
+  a search failure 502 `search_failed`; any other failure, such as a
+  stored recipe that cannot be read, is 500, logged with a fixed reason
+  and the dinner id only — never a candidate's URL or dependency error
+  text.
   `POST /api/v1/dinners/{id}/ground` takes exactly one of `{candidate_id}`,
   `{recipe_url}` (both grounded with `GroundURL`, setting `grounded`) or `{manual: {ingredients[], steps[], minutes,
   method}}` (1–100 ingredient lines, up to 100 steps, each non-blank and at