[ENHANCEMENT] Migrate webview provider comparisons to canonical identifiers

[WebMad]

Problem (one or two sentences)

Webview production code repeats provider identifiers in UI conditions, provider selection, validation, and model configuration logic under webview-ui/src. These values can become inconsistent with the canonical provider registry used by shared and extension code.

Context (who is affected and when)

This affects users when selecting, configuring, or validating providers and models in the webview, and contributors updating provider-specific UI behavior. An incomplete provider update can result in stale options, incorrect defaults, validation errors, or UI behavior that differs from the extension backend.

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 webview comparisons and provider-specific branches should reference canonical identifiers while preserving the current provider options, validation, model defaults, form behavior, and extension messaging. Strings that intentionally represent serialized or external values should remain unchanged where appropriate.

Constraints / preferences (optional)

Keep this issue focused on webview UI production code. Inputs in SettingsView must continue to bind to local cached state rather than live extension state. Code-index provider identifiers such as semble and openai-compatible belong to a separate domain and must not be replaced blindly.

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 webview provider comparisons and branches reference canonical identifiers.
• Existing provider validation, options, model defaults, and form behavior remain unchanged.
• Extension-webview message values remain compatible.
• Intentional serialized, external, test-fixture, and code-index-domain literals remain unchanged where appropriate.
• SettingsView inputs remain bound to local cached state.
• Focused webview tests cover representative migrated UI behavior.

Relevant code locations

• webview-ui/src/utils/validate.ts — provider credential/model validation switch, VS Code LM model lookup, and Zoo Gateway validation branch.
• webview-ui/src/components/settings/utils/providerModelConfig.ts — provider default model maps, custom-model UI collections, Z.ai distinctions, and Bedrock-specific model handling.
• webview-ui/src/components/ui/hooks/useSelectedModel.ts — provider-to-selected-model switch and provider-specific model metadata branches.
• webview-ui/src/components/settings/ApiOptions.tsx — Zoo Gateway auth handling and Bedrock custom ARN checks.
• webview-ui/src/components/settings/ModelPicker.tsx — MiMo-specific pricing UI condition.
• webview-ui/src/components/settings/ModelInfoView.tsx — OpenAI Native tier and Gemini-specific display conditions.
• webview-ui/src/components/settings/providers/LiteLLM.tsx, webview-ui/src/components/settings/providers/OpenCodeGo.tsx, and webview-ui/src/components/settings/providers/Poe.tsx — provider-specific message filtering.
• webview-ui/src/components/chat/CodeIndexPopover.tsx — mixed code-index and API-provider comparisons; migrate only identifiers whose semantics match the canonical API-provider registry, leaving semble and openai-compatible untouched.
• Relevant tests under webview-ui/src/components/settings/__tests__, webview-ui/src/components/settings/utils/__tests__, and webview-ui/src/components/ui/hooks/__tests__ — preserve validation, provider switching, defaults, and selected-model behavior.

Proposed approach (optional)

Identify provider comparisons in webview production code and replace internal API-provider comparisons with shared canonical registry values. Preserve existing component state flow, provider selection, validation, and messaging behavior.

Trade-offs / risks (optional)

A broad replacement could affect option values, validation, extension messaging, or conflate API providers with code-index providers. Each occurrence should be classified before migration, and the scope may be split into smaller component-focused PRs if needed.