Classify model provider rejections

[SaladDay]

What

• The Codex adapter classifies a provider rejection. Codex 0.153.4 reports a provider HTTP 400 as codexErrorInfo: "other" and puts the provider's response body in the Turn error message. When that message is a JSON object with an object error member, the adapter reports that member's own code or type if it is an accepted code (for example an OpenAI-compatible context_length_exceeded), otherwise invalid_request, on the existing Core–Runtime error frame. Any other other message stays unclassified, including a plain-text 400 body and Codex's unexpected status text for provider 401 and 404 responses.
• A failed Codex Turn stores the provider message once. Codex sends the terminal error on the error notification stream and again in turn/completed, and the adapter used to append both. It now appends the buffered notification text only when it differs from the Turn error.
• The Runtime protocol (EN and zh) states the rule: an adapter classifies only from structured error data (the Harness's own error variant or status, or a provider's JSON error body that the Harness passes through) and never from prose. The Codex adapter guide adds the new row. The MiniMax Code guide now says why its failures stay unclassified: MiniMax Code 0.4.12 reports a provider rejection over ACP as JSON-RPC -32603 with prose only.

No wire, Core or declared-code change. Core already maps engine_failed + invalid_request to the invalid_request diagnostic (TestDiagnosticNativeClassification), and invalid_request already counts as a model provider observation.

Why

On mx, the failed Sessions b2f8e093… and f7f09b34… ran Codex against the MiniMax API (https://api.minimaxi.com/v1, Responses) with an unknown model name. MiniMax answered HTTP 400 {"error":{"message":"invalid params, code: 2013, msg: invalid params, unknown model '<model>' (2013)","code":"invalid_prompt"}}. Codex reported other, so the Turn had no engine_error_code, diagnostics showed harness_error and Web said only that the Harness did not report a reason. The stored error repeated the provider message twice.

Verification

• go test ./apps/daemon/internal/agent/codex/ -count=1: pass. The lean test covers a 400 JSON body without a declared code (invalid_request), one with code: context_length_exceeded, one with type: authentication_error, prose and a non-object error, and the single stored message; it reads envelopes with a bounded receive.
• go test ./services/core/internal/api -run TestDiagnostic -count=1: pass.
• make check-runtime-contract: pass.
• go vet ./...: pass.
• make check-names check-docs and the website translation guard (pnpm check-translations): pass.
• Native probe of Codex 0.153.4 through the adapter against a local provider stub (400 JSON, 400 plain text, 401, 404): confirmed the other variant and messages above. These probes were not committed.
• Live adapter run of Codex 0.153.4 against the real MiniMax API with an unknown model: one terminal error with code="invalid_request" and text invalid_prompt: invalid params, code: 2013, msg: invalid params, unknown model 'lane-b-unknown-model' (2013), shown once. This probe was not committed.

Skipped

• Full make check: skipped under the focused-checks rule.
• Live acceptance through Core with a Runtime: skipped. The mx deployment is read-only for this lane, and the adapter-level live run above covers the changed mapping.