Preserve HTTP status codes in LLM history and safe telemetry

docs/llm-gateway-v1.md

@@ -51,6 +51,13 @@ other HTTP configuration failures, refusals, truncated model output, invalid JSO
 schema violations are controlled errors; they are not logged as unreachable servers.
 Adapters execute one call and never retry independently.
 
+HTTP failures additionally preserve an optional numeric `http_status` (100–599).
+Temporary failures record it in `outcome.attempts` or successful failover metadata;
+nonretryable HTTP errors record it in `outcome.http_status`. Existing v1 records
+without this field remain valid. No provider response body, headers or credentials
+are retained. Retry/failover classification is unchanged: 408/429/5xx are temporary;
+a 429 alone does not distinguish rate limits from exhausted quota.
+
 Operational defaults:
 
 | Setting | Default |

docs/telemetry-v1.md

@@ -1,5 +1,12 @@
 # Operational telemetry v1
 
+LLM round events expose numeric `http_status` for nonretryable HTTP failures and
+for every entry in `failed_providers`. Use the `events` CLI to inspect temporary
+provider failures (warning events). For example, 429 indicates a quota/rate-limit
+response; 503 indicates service unavailability. Missing status on older records,
+timeouts or connection errors means unknown, not success. Provider bodies and
+headers are never logged. This field does not change retries or case budgets.
+
 Telemetry observes existing library execution, not case truth. It never resumes
 BLOCKED cases, refills budgets, changes routing, retries a model, edits packages,
 executes tools or deletes case artifacts. `docs/architecture.md` is unchanged.