refactor(providers): dedupe identical opencode-zen/opencode-go model entries

[maxmad64bis]

Summary

opencode-zen and opencode-go are two separate registry entries for the same upstream family (opencode.ai/zen/*), and three models were declared byte-for-byte identically in both: kimi-k2.7-code, qwen3.5-plus, qwen3.6-plus. Copy-pasted metadata like this is exactly how #10874 missed opencode-zen/opencode-go when it fixed Muse Spark's targetFormat only on the base opencode provider.

Extracted the three identical entries into OPENCODE_ZEN_GO_SHARED_MODELS, following the same pattern already used for GLM_SHARED_MODELS in open-sse/config/glmProvider.ts (shared across the glm/glm-t/glm-cn registries). Both opencode-zen and opencode-go now spread this array instead of repeating the entries inline. A future metadata fix (routing, reasoning flags, etc.) for any of these three models only needs to land in one file.

Scope is intentionally narrow: only entries that were already byte-identical across both files were moved. Models with tier-specific flags (e.g. opencode-go's effort-tier variants, or fields only one side declares) were left untouched — merging those would be a silent behavior change, not a dedupe. command-code and freebuff also list similarly-named models but are different upstream/executor pairs entirely — not touched here.

Related Issues

• Related to fix(providers): Muse Spark still returns empty content on opencode-zen and opencode-go (targetFormat missed by #10874) #11048 / fix(providers): route Muse Spark to the Responses API on opencode-zen and opencode-go too #11049 (that PR's Reviewer Notes flagged this exact duplication as a likely follow-up)
• No dedicated bug issue — this is a proactive refactor, not a user-facing fix

Validation

• Change type: provider (registry data — open-sse/config/providers/registry/opencode/{zen,go}/index.ts, open-sse/config/opencodeZenGoSharedModels.ts)
• node --import tsx/esm --test tests/unit/opencode-zen-go-shared-models.test.ts — 3/3
• npm run typecheck:core — clean
• npm run check:cycles — no cycles
• npm run check:provider-consistency — OK, 267 registry entries, 348 canonical providers, 0 exceptions
• Branched from current release/v3.8.50 tip

⚠️ base-red inherited: #9985

Tests Added Or Updated

tests/unit/opencode-zen-go-shared-models.test.ts:

• Every OPENCODE_ZEN_GO_SHARED_MODELS entry is present exactly once, unmodified, in opencode-zen
• Every OPENCODE_ZEN_GO_SHARED_MODELS entry is present exactly once, unmodified, in opencode-go
• The shared array is frozen (guards against one registry mutating it and silently affecting the other)

Coverage Notes

Registry data only — no logic changes. Covered by the new test plus the full existing suites for both registries and check:provider-consistency.

Reviewer Notes

Pure move, no behavior change: same 3 model ids, same field values, same position in each registry's live catalog. The check:provider-consistency gate (267 registry entries, 348 canonical providers, 0 exceptions) and the deep-equal assertions in the new test are what actually prove nothing drifted during the extraction.

[diegosouzapw]

Nice, clean refactor — this matches the GLM_SHARED_MODELS pattern exactly and the regression test is a good guard. I verified locally that no model is lost: the model-id set for both providers is identical before/after, check:provider-consistency still passes (267/0), and the existing #8353 effort-alias test still passes 38/38.

Two optional notes (non-blocking):

1. open-sse/config/providers/registry/opencode/go/index.ts:17 and .../zen/index.ts:19 — the shared spread is placed at the TOP of models, so the array order changes. go[0] becomes kimi-k2.7-code (was glm-5.2) and zen[0] becomes kimi-k2.7-code (was big-pickle). Since the dashboard picks models[0] as the default (e.g. LlmChatCard.tsx:178, ProviderTestSlideOver.tsx:63), this silently changes each provider's default selected model. If you want a byte-identical refactor, insert the spread where the three entries originally sat (after the GLM block in go, after kimi in zen) — or explicitly call out the new default as intended.
2. tests/unit/opencode-zen-go-shared-models.test.ts only asserts the SHARED entries are present/unmodified; it wouldn't catch a future accidental deletion of a non-shared entry (e.g. minimax-m3, glm-5.1). Consider a broader assertion that the full model-id set matches a fixed "golden" list for each provider.

No blocking changes — happy to merge as-is.

[maxmad64bis]

Thanks — addressed in follow-up PR #11133.

Default-model nit: confirmed on upstream/release/v3.8.50 the OPENCODE_ZEN_GO_SHARED_MODELS spread is at models[0] for both opencode-go and opencode-zen, so the dashboard default had silently become kimi-k2.7-code (the dashboard takes models[0], ~14 call sites). Moved the spread after glm-5.2 (go) / big-pickle (zen) to restore the original models[0]. I did not try to reproduce the exact pre-#11051 interleaving — the three deduplicated entries were scattered in non-contiguous slots, so a single spread can't restore them and it isn't needed; the goal is the models[0] default.

Golden-list nit: instead of freezing the full model-id catalog (which zen/index.ts documents as live-regenerated via passthroughModels: true — a snapshot would red on every legitimate sync), I added two narrow guards: (a) referenced non-shared ids minimax-m3 / glm-5.1 must remain present, (b) models[0].id must stay glm-5.2 / big-pickle. These lock the real invariants the nit is about.

Also folded in the #11049 overlay comment (zen muse-spark-1.2-contributor-free marked as an explicit wire-format overlay of the base provider to avoid catalog-sync drift). check:provider-consistency stays 267/0.