fix(desktop): report the model actually tested when Test Connection falls back

[liuxiaocs7]

Summary

For an OpenCode Free connection, "测试连接 (Test Connection)" probes the enabled models then the provider fallbacks and returns the first model that answers (testConnectionStrict, packages/runtime/src/test-connection.ts:166-195). When the selected model (e.g. mimo-v2.5-free) is rate-limited, temporarily down, or returns an empty completion, the loop falls through to a fallback model (nemotron-3-ultra-free, the provider default) and the success toast reports that model — reading as if the user's model selection never took, and hiding that their chosen model is currently unavailable.

The probe-until-one-answers behavior is intentional and worth keeping (free models rotate and rate-limit). The fix is scoped to the renderer: runTest now compares result.modelTested against the enabled model ids. When the answering model isn't one the user selected, it shows a warning toast that names the unresponsive selection and the model used to verify, instead of a plain green success. When the selected model does answer, behavior is unchanged.

No runtime / IPC / persisted types were touched — the renderer already has both facts (the enabled set and modelTested), so the detection lives entirely in use-connection-detail.ts plus two new copy strings (zh + en).

Fixes #4222

Verification

• npm run typecheck in apps/desktop (preload + main + renderer + storybook) — passes.
• Not run: lint/format, unit/e2e suites, and a live app launch — the trigger is an OpenCode Free free-model rate-limit/empty-completion, which isn't reliably reproducible on demand. The success-path (selected model answers) is unchanged; only the fallback path switches to a warning toast.

Review focus

• The detection guard: testedId !== undefined && enabledModelIds.length > 0 && !enabledModelIds.includes(testedId). For non-opencode-free providers the backend returns the first enabled candidate, so modelTested is always in the enabled set and the warning never fires. The length > 0 guard avoids a spurious warning for a zero-model connection that verifies its credential against a fallback.

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Claude Code (Opus 4.8) diagnosed the root cause and authored the fix and copy. The affected commit carries a Generated-by: Claude Code (Opus 4.8) trailer.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[jackwener]

I found no blocking issues on 694fbf224d9406a4c4170aca7bedcedd4320744a.

The runtime already returns the exact model that answered after probing every enabled OpenCode Free model before provider fallbacks. This renderer-only change preserves that behavior and correctly distinguishes the three relevant outcomes: a selected model answered, every selected model failed and an unselected fallback answered, or no model is selected and a fallback is used only to verify the connection. The warning names both the selected models and the answering fallback without changing persisted state, IPC, or send authority.

I verified the Desktop preload/main/renderer/Storybook typecheck, the seven OpenCode Free runtime fallback tests, Biome, diff-check, ASF headers, the clean current-main merge result, and the successful exact-head hosted test check.

---

Automated review notice: This comment was posted by an automated review agent operated by WAWQAQ. It is not an independent human review and does not replace one.