[ENHANCEMENT] Migrate extension-side provider comparisons to canonical identifiers

[WebMad]

Problem (one or two sentences)

Extension-side production code still compares provider names using raw string literals, including provider-specific branches under src/core. These comparisons duplicate the canonical definitions and make provider migrations harder to complete safely.

Context (who is affected and when)

This affects maintainers working on extension state, configuration, profile handling, authentication, and webview message processing. Missing one comparison during a provider change may leave only a particular extension workflow inconsistent.

This is part of the provider identifier centralization tracked by #944 and depends on the foundational registry introduced by #951.

Desired behavior (conceptual, not technical)

Internal extension logic should use canonical provider identifiers for provider comparisons and branches. Existing extension workflows, persisted settings, messages, and provider-specific behavior should remain unchanged.

Constraints / preferences (optional)

Keep serialized values, external message payloads, fixtures, translations, documentation, and separate code-index provider identifiers as literals where appropriate. This issue should cover extension-side production logic, not webview UI code.

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear context and impact

Zoo Code Task Links (optional)

Parent tracking issue: #944

Foundational identifier registry: #951

Acceptance criteria (optional)

• Appropriate extension-side provider comparisons and branches reference canonical identifiers.
• Persisted settings and extension-webview message values remain unchanged.
• Intentional external or serialized literals are not replaced unnecessarily.
• Code-index provider names that are not API provider identifiers are not migrated accidentally.
• Focused tests cover representative migrated extension workflows.
• Existing extension tests continue to pass.

Relevant code locations

• src/core/webview/ClineProvider.ts — LM Studio startup behavior and Zoo Gateway profile filtering/authentication branches.
• src/core/webview/webviewMessageHandler.ts — Zoo Gateway active-profile and all-profile comparisons, plus review of router model requests.
• src/core/task/Task.ts — provider-specific runtime capability checks such as Gemini allowed function names.
• src/core/config/ProviderSettingsManager.ts and src/core/config/ContextProxy.ts — review active/retired provider validation paths; these already use guards in several places and should not be changed unnecessarily.
• src/core/config/importExport.ts — review persisted profile handling without changing serialized values.
• Tests under src/core/webview/__tests__, src/core/config/__tests__, and src/core/task/__tests__ — preserve representative workflow coverage.
• src/services/code-index/service-factory.ts and src/shared/embeddingModels.ts — review carefully but do not replace semble or openai-compatible with API-provider registry values; code-index providers are a separate domain. Shared names may be migrated only when their types and semantics match the API provider registry.

Proposed approach (optional)

Identify provider comparisons in extension production code and replace internal API-provider comparisons with canonical registry values. Keep the scope separate from webview UI migration and preserve all runtime behavior.

Trade-offs / risks (optional)

A broad mechanical replacement could incorrectly change serialized or external values or conflate API providers with code-index providers. Each occurrence should be classified before migration, and the PR may be split further if the resulting scope is too large.