Add Qwen provider (OpenAI-compatible BYOK) - #57

Reviewed changes — adds a first-class Qwen provider (OpenAI-compatible BYOK) so coding/review runs can target DashScope or any compatible gateway with a bring-your-own key.

• Register qwen provider in models.ts — three aliases (qwen-coder → qwen3-coder-plus preferred, qwen-plus, qwen-max), each with an openRouterResolve equivalent.
• Inject qwen into action-owned OPENCODE_CONFIG_CONTENT — both agents/opencode.ts and agents/opencode_v2.ts materialize a @ai-sdk/openai-compatible provider, with key/baseURL resolved from QWEN_* → DASHSCOPE_* → LLM_* and the DashScope international URL as default.
• Relax opencode key validation in utils/apiKeys.ts — accept any recognized Qwen env var as sufficient, since the custom provider config doesn't exist yet at opencode models introspection time.
• Tests — model env-var/slug resolution and the new key-validation early return.

⚠️ Qwen resolve targets a provider models.dev doesn't have, breaking the catalog drift gate

The catalog drift test walks every non-routing, non-deprecated alias and asserts data[provider] exists on models.dev, where provider is the slug prefix of resolve. The three Qwen aliases resolve to qwen/…, but models.dev has no qwen provider — its Qwen models live under alibaba-cn. Every other provider in the catalog (anthropic, openai, opencode, …) resolves to a real models.dev provider key, which is why this gate passes on main today; qwen is the first that won't.

This gate lives in *.main.test.ts, which vitest.config.ts excludes from pnpm test, so a clean local run won't surface it — it only fires via pnpm test:catalog (the documented integrity gate for catalog edits). The runtime feature is unaffected: OpenCode uses the injected custom provider config, not models.dev, to resolve qwen/qwen3-coder-plus.

# Qwen `resolve` provider prefix is absent from models.dev

## Affected sites
- `models.ts:282` — `resolve: "qwen/qwen3-coder-plus"`
- `models.ts:288` — `resolve: "qwen/qwen-plus"`
- `models.ts:293` — `resolve: "qwen/qwen-max"`
- `test/models-catalog.main.test.ts:44-77` — `models.dev validity` block: `expect(data[parsed.provider]).toBeDefined()` fails because `data["qwen"]` is undefined (Qwen is under `alibaba-cn`).

## Why CI here is green but the gate isn't
- `vitest.config.ts` excludes `**/*.main.test.ts` from `pnpm test`; the drift suite only runs via `pnpm test:catalog` (`vitest.main.config.ts`). The PR's `pnpm test` therefore never exercises this.

## Required outcome
- The Qwen aliases must not fail the `models.dev validity` existence check, while keeping `resolve: "qwen/…"` (the prefix must match the injected OpenCode provider key for runtime resolution).

## Suggested approach
- Treat Qwen as a BYOK custom provider with no upstream models.dev entry — analogous to the `routing` slugs the test already skips (`if (alias.routing) continue;`). Add a comparable skip for the `qwen` provider in the `models.dev validity` block (and confirm the `openRouterResolve` blocks below behave as intended).

## Open questions for the human
- Run `pnpm test:catalog` and confirm the `openRouterResolve` checks pass too. `qwen-max` maps to `openrouter/qwen/qwen3-max` (note: `qwen3-max`, not `qwen-max`) — verify that ID is live on both models.dev's `openrouter` provider and the OpenRouter `/api/v1/models` list, since those two checks aren't excluded and would fail independently if the ID drifted.
- Decide whether Qwen aliases should be subject to drift checks at all, or fully exempt like the routing slugs.

ℹ️ Nitpicks

• The qwenApiKey / qwenBaseUrl resolution and the qwen provider block are duplicated verbatim in agents/opencode.ts (lines 97-157) and agents/opencode_v2.ts (lines 107-154). Other shared OpenCode config lives in opencodeShared.ts (e.g. geminiHighThinkingOverrides); a small shared helper would prevent the two copies drifting. Defensible to leave given v1 is slated for retirement.

  ^{｜ Fix it ➔ ｜ View workflow run ｜ Using Claude Opus (free via Pullfrog for OSS) ｜ 𝕏}

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 7776a48. Configure here.}