fix(routing): stop round-robin combo opencode targets from collapsing onto opencode-zen (#11912)

[diegosouzapw]

Closes #11912

Root cause

open-sse/services/model.ts's manual ALIAS_TO_PROVIDER_ID["opencode"] = "opencode-zen" override canonicalizes ANY "opencode/<model>" string to provider opencode-zen (the api-key gateway) before dispatch. A round-robin combo mixing declared "opencode/<model>" targets (intended as the free/dynamic no-auth pool) with an explicit "opencode-zen/<model>" target therefore collapsed every rotation slot onto the same provider + connection identity — every request executed against the single opencode-zen connection instead of rotating across the free pool, matching the reporter's upstream-log screenshots (100% of traffic landing on opencode-zen, eventually 429ing). The same collapse explained the reported dashboard metrics desync: src/lib/combos/controlCenter.ts's providerFromModel() labeled targets from a raw, un-aliased string slice, so the "Resolved Runtime Targets" panel and the actual dispatched identity disagreed.

Fix

Scoped to combo target resolution only — open-sse/services/model.ts's general alias-resolution path is untouched, so a raw client request to "opencode/<model>" outside a combo keeps routing to opencode-zen unchanged (#2798/#3870), and the #7993 sibling credential lookup (tests/unit/opencode-autocombo-search-pair.test.ts) is unaffected.

• New open-sse/services/combo/opencodeTargetAlias.ts: resolveComboTargetModelStr() rewrites an ambiguous "opencode/<model>" combo target to the "oc/" no-auth alias, mirroring the combo builder's existing [BUG] OpenCode Free combo entries use opencode/ prefix instead of oc/ #2901 guard (src/lib/combos/builderOptions.ts).
• open-sse/services/combo/comboStructure.ts's normalizeRuntimeStep() (the single shared resolution point for every combo strategy) applies that rewrite before the model string reaches dispatch, so "opencode/<model>" and "opencode-zen/<model>" targets stay distinct rotation identities.
• src/lib/combos/controlCenter.ts's providerFromModel() resolves labels through the same alias-normalization path (plus the existing resolveProviderAlias), so the dashboard label matches what actually executes upstream.

Regression test

tests/unit/issue-11912-opencode-roundrobin-collapse.test.ts

• RED (against origin/release/v3.8.51, comboStructure.ts unfixed): AssertionError [ERR_ASSERTION]: Expected values to be strictly equal: + 'opencode-zen' - 'opencode'
• GREEN (with the fix): both new tests pass.

Gates run

• node scripts/check/check-file-size.mjs — no ✗ for touched files
• node scripts/check/check-complexity.mjs — OK (2798 violations vs baseline 3218)
• node scripts/check/check-cognitive-complexity.mjs — OK (1265 violations vs baseline 1437)
• npm run typecheck:core — exit 0
• npx eslint --suppressions-location config/quality/eslint-suppressions.json <changed files> — exit 0
• New test: node --import tsx/esm --test tests/unit/issue-11912-opencode-roundrobin-collapse.test.ts — 2/2 pass
• Existing combo/round-robin/opencode suites re-run together (147 tests, 0 failures): tests/unit/combo/round-robin-combo.test.ts, tests/unit/combo-pin-implicit-allowlist.test.ts, tests/unit/combo-routing-engine.test.ts, tests/unit/combo-scoring-inspector.test.ts, tests/unit/opencode-autocombo-search-pair.test.ts, tests/unit/refactor-buildHeaders-opencode.test.ts, tests/unit/model-alias-seed-fallback.test.ts, tests/unit/combo-control-center.test.ts, tests/unit/fusion-vision-panel-3378.test.ts
• node scripts/check/check-changelog-integrity.mjs — OK

⚠️ base-red inherited: #12732 — unit #12058, integration codex-cache, package-artifact, tarball-smoke, agent-skills-sync

[HouMinXi]

Heads-up: applied on top of release/v3.8.51, this PR breaks npm run build (webpack).

src/lib/combos/controlCenter.ts is reachable from the client component src/app/(dashboard)/dashboard/combos/ComboControlCenterClient.tsx. The two new imports

import { resolveComboTargetModelStr } from "../../../open-sse/services/combo/opencodeTargetAlias.ts";
import { resolveProviderAlias } from "../../../open-sse/services/model.ts";

pull the server-side open-sse graph into the browser bundle. The build then fails with:

./node_modules/detect-libc/lib/detect-libc.js
Module not found: Can't resolve 'child_process'

Import trace:
./node_modules/sharp/dist/utility.mjs
./open-sse/utils/cursorImages.ts
./open-sse/executors/zai-web.ts
./src/lib/providers/validation/webCookie.ts
./src/lib/tokenHealthCheckWebCookie.ts
./src/lib/tokenHealthCheck.ts
./src/lib/config/runtimeSettings.ts
./src/lib/db/settings.ts
./src/lib/db/readCache.ts
./open-sse/services/model.ts
./src/lib/combos/controlCenter.ts
./src/app/(dashboard)/dashboard/combos/ComboControlCenterClient.tsx

Same chain also produces Can't resolve 'fs' (open-sse/config/credentialLoader.ts) and Can't resolve 'module' (open-sse/executors/codex.ts).

The alias resolution needs to stay server-side. Two options: normalize the label in the API route that serves the control-center data instead of in the shared module, or move the two helpers into a small dependency-free module that does not transitively import open-sse/services/model.ts.

Two side notes:

• The explicit .ts extensions on those imports are inconsistent with the rest of the codebase and may trip other bundler configs.
• Dropping those two imports and reverting providerFromModel to the prefix slice restores the build; the label then shows the raw prefix for opencode combos, which is cosmetic only.