Enhancement: codex-executor auto-fallback to a secondary model when the primary is down

Problem

On 2026-06-15, openai.gpt-5.5 on bedrock-mantle returned server_error for every request (even trivial input) in both us-east-1 and us-east-2 — an AWS-side outage of that specific model. Meanwhile openai.gpt-5.4 and openai.gpt-oss-120b were healthy in the same account/region/auth.

Result: every automatic GPT-5.5 PR review in dotCMS/core failed for the duration of the outage. v3.1.5 makes the failure legible (surfaces response.error, retries once on transient response.failed, posts a ❌ "model service error" sticky + red ✗), but it does not keep reviews working — a one-model outage takes the whole review path down.

Proposed enhancement

Add an optional fallback model to codex-executor: when the primary model fails (response.failed / server_error, or repeated empties) even after the existing retry, automatically re-run the review on a configured secondary model and post that result, clearly labeled with which model produced it.

Sketch

• New input fallback_model_id (optional, e.g. openai.gpt-5.4). Empty = current behavior (no fallback).
• Flow: try primary → (existing retry) → if still failed/empty, try fallback_model_id once.
• Sticky shows the model that produced the review and notes the primary was unavailable (e.g. "⚠️ Reviewed with openai.gpt-5.4 — openai.gpt-5.5 was unavailable (server_error)").
• Pick the fallback path by model id, same as today (/openai/v1 vs /v1).
• Consider whether the fallback also applies to incomplete-empty, or only to failed.

dotCMS/core hookup (after this ships)

Keep primary openai.gpt-5.5, set fallback_model_id: openai.gpt-5.4 so reviews stay up through a single-model outage and auto-return to gpt-5.5 when it recovers.

Context

• Investigation + the v3.1.5 error-surfacing fix: ai-workflows#40
• Related: ai-workflows#38 (incomplete/token-budget), #39 (outcome signaling)

The entry point is codex-executor; first read its existing retry and v3.1.5 error-surfacing path described in this issue. Trace primary and fallback model selection plus sticky output, then verify that an empty fallback preserves current behavior and a failed primary produces a clearly labeled secondary-model review.