fix(opencode): record the free-tier refusal instead of counting it as success

[maxmad64bis]

⚠️ base-red inherited: #14004

Summary

The OpenCode free tier has been answering 403 since 2026-09-17, and OmniRoute treats that refusal as a healthy response: it is never classified, nothing is recorded on the connection, and the account that was just refused is marked successful — clearing the failure history that drives its cooldown. A refusal improves the rotation health of the account it hits. One layer up, the per-model lockout arm (#3027/#12242) also recorded it as this model being forbidden on this connection; since every sibling account answers the same request the same way, one refusal per account empties the pool, after which requests that would have been served are answered no active credentials.

The refusal is scoped to the request, not the account or the model: four different API keys and an anonymous request return the same 403 for the same request, and the same key returns 200 once the request matches the upstream contract. So it is now recognized, returned unchanged without a pointless hop across accounts, recorded as a non-banning routing error, and leaves rotation state alone. Every other 403 keeps its existing handling. Behaviour change worth calling out: the account-health reset now requires an HTTP success, where previously any status without a dedicated branch (403, 451, 401, 404, 422, and a 400 carrying a real upstream error) reset the failure history.

This does not make the free tier work again — the request contract is a separate concern, tracked in #13935 and addressed by #14013. It makes the failure honest.

Related Issues

• Related to [BUG] OpenCode free provider returns 403 for all API requests through OmniRoute #13935

Validation

• Change type: provider
• Focused tests and category gates from the golden path
• npm run lint — clean on the touched files with the repository suppressions; the full run is not green on the base
• Reconciled with the current active release base; focused checks rerun afterward
• Production-code changes include a new or updated automated test in this PR

Tests Added Or Updated

• opencode-free-tier-refusal-predicate.test.ts (new): the predicate on the verbatim body and on the relayed message alone, 403 and 451 alike, precedence over the geo-block, user_blocked and fingerprint predicates, edge bodies and statuses, the provider scope, and and a parity table pinning the executor predicate, the classifier and the auth guard to the same vectors, including the 402 that must stay a per-model credit failure.
• opencode-free-tier-refusal-rotation.test.ts (new): returned as-is with one upstream call and no rotation, history and cooldown untouched; a 400 carrying a real error and an unhandled 401 no longer reset the account; a success still does.
• opencode-free-tier-refusal-no-model-lockout.test.ts (new): the refusal leaves the model usable on the account it landed on and the connection active and uncooled, while a foreign provider echoing the sentence, and a 402 carrying it, both keep their existing handling. Negative controls: removing the guard fails the first case, widening the recognition to 402 fails the last, and dropping the provider scope fails the scope case.

Coverage Notes

• opencodeGeoBlock.ts and errorClassifier.ts by the predicate file, including every exclusion vector and an ordinary api-key 403 that must stay unclassified; opencode.ts and the extracted opencodeAccountHealth.ts by the rotation file, which drives the real executor loop with a stubbed upstream; auth.ts by the third file, through markAccountUnavailable against a real connection.

Reviewer Notes

Why an early return in auth.ts rather than an extra condition. Excluding the refusal from the per-model arm alone sends it into the connection-wide path, which marks the whole connection unavailable — worse than the lockout it avoids. The early return sits before any state write, mirroring the existing isTerminalConnectionStatus guard in the same function, and is scoped to opencode* the same way classifyProviderError scopes it.

Why PROJECT_ROUTE_ERROR. FORBIDDEN writes the terminal banned state, GEO_BLOCKED parks the connection 24h, FINGERPRINT_REJECTION describes a CDN signature refusal. PROJECT_ROUTE_ERROR is the existing family for "recoverable, explicitly not a ban". The gain is a correct error_type in the call log instead of unknown, not new routing behaviour. Recognition keys on the sentence because parseUpstreamError keeps error.type aside, so matching the token alone would never fire in production.

Ordering with open PRs on these files. #13548 widens the same per-model arm for credit exhaustion — textual conflict likely, and both move the same way: it takes a failure from the connection down to the model, this takes one from the model down to the request. #12340 does the same for another provider family. #13161 widens the fingerprint predicate, which this one excludes before matching.

Inherited gates. check-api-typecheck fails identically at the bare base (codex-responses-ws/route.ts, chat.ts), neither touched here; the test file-size gate flags chatcore-translation-paths.test.ts, untouched, same drift as #14004. opencode.ts ends at 1182 against a 1200 cap; auth.ts gains 5 lines and stays under its frozen size.

[diegosouzapw]

Thanks @maxmad64bis — merging via the release merge-train. Validated in local merge-train (.claude/worktrees/merge-train-20260918-111718-suite.log) on the devbox @ train tip 7bb373fba5e241964c0ffb17bd03a804700839bb, boarded with 55 sibling PRs: typecheck:core, file-size, complexity, cognitive-complexity, changelog-integrity green; 747/747 changed-area node:test cases + 476/476 vitest green (fast parity mode — the full suite ran today on the release tip via the base-red train and runs again on the 3b train). Merged --admin per merge-gates §7.