fix(microsoft): use Chat Completions for custom Qwen-compatible endpoints

[duc15052006-dotcom]

Why

Microsoft Agent Framework currently uses OpenAIChatClient (Responses API) even when the user configures an OpenAI-compatible custom base URL. Qwen/xKiro, Ollama, vLLM and similar services commonly expose /v1/chat/completions without /v1/responses, so correctly entered keys/models can still fail during actual runs.

Changes

• Select Microsoft OpenAIChatCompletionClient only when OPENAI_BASE_URL is explicitly configured; preserve first-party OpenAI Responses API and its hosted-tool features when no custom endpoint is configured.
• Extend the in-process provider regression fixture to a real Chat Completions SSE endpoint and prove chosen model reaches that endpoint.
• Add a regression that the default OpenAI route retains the Responses API client; keep the synthetic Anthropic endpoint-key test from PR fix(computer): recover from changed network configuration on restart #194.

Safety

• All test keys are synthetic; no real external API call is needed.
• No changes to how desktop encrypts, stores or exposes API keys.
• Existing local function tools remain supported by Chat Completions in Microsoft Agent Framework; intentionally avoid changing default OpenAI mode.

Dependency / merge order

PR #194 has merged into verify/release-candidate as 3b95852c44e84965cf44dd367f657de4584b86c5; this PR has been retargeted to that exact release-candidate base. Verify this PR's own CI on its HEAD (612f45fb0fc442058322a27bcc12eaa915313321) before any merge. Do not merge PR #30. Live Windows acceptance and real external Qwen/xKiro endpoint verification are not yet established.