docs(reliability): fallback target needs a real sk-ant-api03 key, not an OAuth token

Record the empirical finding: a Claude subscription OAuth token is gated by
Anthropic (404/429 as a raw API) and can't serve as the server-side fallback,
even though mcpd's adapter now sends it via Bearer. The anthropic-fallback is
wired-but-inert until mcpd Secret anthropic-key holds a real console API key.
Also note the chain is now Pulumi-owned so pulumi up won't wipe it.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/reliability.md

@@ -48,4 +48,18 @@ model actually answered**.
   model + upstream status/body (not "no choice").
 
 Homelab chain: `vllm-current` (the served vLLM) → an `anthropic-fallback` server
-Llm as the always-up last resort.
+Llm as the always-up last resort. The chain is owned declaratively by Pulumi
+(`kubernetes-deployment/deployments/mcpctl/llm-target.ts`, `fallbacks` arg) so a
+`pulumi up` can't wipe it — mcpd *replaces* `extraConfig` on update.
+
+**A real last resort needs an independent cloud credential.** LiteLLM only fronts
+the single local vLLM, so any local model shares the same GPU-box failure as the
+primary. `anthropic-fallback` points at `api.anthropic.com` and only serves once
+mcpd Secret `anthropic-key` holds a genuine **`sk-ant-api03` API key** (from the
+Anthropic Console). A Claude *subscription* OAuth token (`sk-ant-oat…`, what
+`claude setup-token` mints) does **not** work: Anthropic gates those to the Claude
+Code client — probed directly they 404 on older model ids and 429 on current ones.
+mcpd's anthropic adapter does send OAuth tokens via `Authorization: Bearer` (so
+auth *passes*), but the gating is server-side and unavoidable. Until a real key is
+set, the fallback is wired-but-inert: an outage fails over to it and surfaces a
+clear `anthropic-fallback (model) HTTP 4xx` error rather than improving uptime.