fix(resilience): Grok Build OAuth 403 content refusal is a per-request rejection, not a ban (#14258)

[sprintberlin]

Summary

• A Grok Build OAuth content refusal (403 "I can't help with that request.") was classified as FORBIDDEN and persisted as the terminal banned connection state. From then on every later request was answered locally with [grok-cli] All 1 connection(s) banned by upstream — please reconnect in the dashboard until an operator reconnected.
• That 403 is a per-request safety refusal, not a dead credential: the same token answered 200 16 s before the event, a token refresh succeeded 3 s before it, and an in-flight call completed 200 2 s after it. The account was never banned by xAI.
• Because grok-cli is authType: "oauth", it skipped the recoverable API-key 403 short-circuit and fell through to the generic OAuth FORBIDDEN default. The Anthropic carve-out from fix(sse): Anthropic OAuth 403 "Request not allowed" is a per-request refusal — cooldown with backoff instead of an instant ban (#12859) #12864 (Request not allowed) does not match this body.

Related Issues

• Closes fix(resilience): errorClassifier: Grok Build OAuth 403 "I can't help with that request." permanently bans a healthy grok-cli connection #14258
• Related to fix(resilience): errorClassifier: Anthropic OAuth 403 "Request not allowed" permanently bans the Claude connection on a single response #12859 / fix(sse): Anthropic OAuth 403 "Request not allowed" is a per-request refusal — cooldown with backoff instead of an instant ban (#12859) #12864 (same request-refusal-versus-account-ban defect on Anthropic OAuth)
• Related to fix(resilience): errorClassifier: a Cloudflare managed challenge on Codex /responses/input_tokens permanently bans a healthy Codex OAuth connection #13157 (another non-account 403 that must be classified before the generic OAuth FORBIDDEN fall-through)

Validation

• Change type: routing / other (error classification)
• Focused tests and category gates from the golden path
• npx prettier --check and npx eslint on the changed files
• Reconciled with the current active release base (release/v3.8.51 at 7a921299c5); focused checks rerun afterward
• Production-code changes include a new or updated automated test in this PR
• SonarQube is temporarily opt-in while the private project has no quota; it is not a PR gate.

Tests Added Or Updated

• tests/unit/grok-request-refusal-not-a-ban.test.ts (new)
• Neighbor suites rerun unchanged: tests/unit/anthropic-request-not-allowed-not-a-ban.test.ts, tests/unit/error-classifier.test.ts, tests/unit/request-rejected-streak.test.ts

Coverage Notes

• The new test pins classifyProviderError() and resolveTerminalConnectionStatus() on the verbatim wrapped xAI body, the plain-text and JSON-wrapped variants, and a generic grok-cli 403 that must still remain FORBIDDEN.
• Existing Anthropic refusal and classifier suites cover the sibling path and the rest of the 403 ladder.
• Coverage should not drop: this is an additive classifier branch plus a new test file.

Reviewer Notes

• Why this is scoped to grok-cli and this phrase: the production body is I can't help with that request.; matching it on other providers would hide genuine account-level 403s. The Anthropic helper stays provider-scoped for the same reason.
• Why REQUEST_REJECTED instead of null or FINGERPRINT_REJECTION: null would skip cooldown entirely and keep retrying a refusing model; FINGERPRINT_REJECTION is a CDN/client-signature class. The existing handleRequestRejectedFailure() leaf already implements the intended policy (5 min → 15 min → terminal only on 3 consecutive refusals, probes never escalate).
• Why not reopen fix(resilience): errorClassifier: Anthropic OAuth 403 "Request not allowed" permanently bans the Claude connection on a single response #12859: that issue was closed by the implementing PR fix(sse): Anthropic OAuth 403 "Request not allowed" is a per-request refusal — cooldown with backoff instead of an instant ban (#12859) #12864, and its Anthropic-specific body match is still correct. This is a sibling, not a regression of that fix.
• Clean inputs pass through unchanged: every other grok-cli 403, every Anthropic 403, and every API-key 403 keep their previous classification.
• No production runtime change on our deployment until this lands in an official release. Live currently runs stock 3.8.50; this PR targets the active cycle release/v3.8.51.
• ⚠️ base-red inherited: 🔴 Release branch not green: release/v3.8.51 #13866 (Release branch not green: release/v3.8.51).

[diegosouzapw]

This is a solid, well-evidenced fix — the request-refusal-vs-ban distinction is exactly right and the test pins both the new branch and a regression guard so a genuine account ban still resolves to banned. Before we merge: your CI run shows red across typecheck/eslint/docs-gates/all 4 unit shards, which is broader than the #13866 inherited base-red you flagged. Can you rebase onto the current release/v3.8.51 tip and re-run so we can confirm it's only the known #13866 set and nothing new?

[sprintberlin]

Rebased onto the current release/v3.8.51 tip (893fef9). The two request-refusal tests pass locally and typecheck:core is clean. The remaining CI failures match the inherited #13866 base-red set.

[sprintberlin]

Re-synced onto the current release/v3.8.51 tip after #14290 landed (34113170). The two request-refusal tests still pass locally and typecheck:core is clean. Remaining CI failures continue to match the inherited #13866 base-red set.

[sprintberlin]

Rebased onto the current release/v3.8.51 tip (2b8f89a6, including the #14331 base-red drain and #14437 merge-train i18n gate fix). The focused Grok request-refusal test passes (2/2), and npm run typecheck:core is clean. This force-push has started a fresh CI run.