[tonyandrewmeyer]

The enricher now retries a rate limit, 5xx, timeout or dropped connection up to twice, and asks OpenRouter for deepseek/deepseek-v3.2 when the configured model errors. The first scheduled failure in operator since the enricher was wired up (run 37491405242, commented on canonical/operator#2750) got a single 429 back from OpenRouter, so it posted the plain body. deepseek/deepseek-chat currently has only two providers that support structured output, so one of them rate-limiting halves the pool (v3.2 has ten).

• Waits are 5s then 15s, or the Retry-After if OpenRouter sends one, capped at 30s each and a minute in total. Each attempt keeps the existing 60s timeout, so the worst case is about four minutes of runner time. Other 4xx aren't retried, because a 400 is the request and a 402 is the key's credit.
• The fallback uses OpenRouter's models list (deepseek-chat then v3.2, with OPENROUTER_MODEL ahead of both if it's set, rather than in place of deepseek-chat), which only moves on when a model errors. The request now sends models without model, which is what the fallback docs show.
• The model that answered goes in the job log and in a separate hidden <!-- ai-failure-notifications:model ... --> comment next to the marker. None of the existing marker parsers match it, so artefacts written by the current release still parse and older releases can read the new ones.

I ran v3.2 over the canary fixtures (all 18 cells, three times each, with v3.2 as the primary so every answer was its own). It drops and attaches the same duplicates as deepseek-chat, it never commented on the wrong issue or invented one, and every envelope was valid. However, every reply from two of its providers (Venice and DeepInfra) came back wrapped in a ```json fence that json.loads can't parse, so the last commit unwraps a fence around the whole reply before validating it. The package's own retry never fired, because OpenRouter moved the 429s to v3.2 itself, so that path is only covered by the unit tests.

[james-garner-canonical]

Makes sense. One non-blocking concern about how OPENROUTER_MODEL replaces one default but not the rest -- I think it should either prepend (not replace), or be a list that replaces all the default models. The latter is probably safer if the use case is to control what models are requested, but prepending makes sense if the use case is only to control what model is tried first.