[ENHANCEMENT] Replace remaining production provider literals and verify canonical identifier coverage

[WebMad]

Problem (one or two sentences)

After migrating the main provider consumers, isolated raw provider-name literals may remain in production code. These remaining comparisons could continue to bypass the canonical registry and leave the provider identifier centralization incomplete.

Context (who is affected and when)

This affects maintainers and contributors during future provider additions, renames, and retirements. It is especially relevant after the targeted migrations, when remaining literals need to be classified as internal comparisons or intentional serialized, external, test, translation, documentation, model-name, or separate-domain values.

This is the final cleanup stage of the provider identifier centralization tracked by #944 and should follow the targeted consumer migrations.

Desired behavior (conceptual, not technical)

All appropriate production comparisons, switch cases, and internal collections should use canonical provider identifiers. Intentional literals in persisted data, external formats, fixtures, translations, documentation, model IDs, and separate provider domains should remain readable and stable, with focused regression coverage confirming the completed migration.

Constraints / preferences (optional)

Do not perform blind global replacement. Serialized values, external formats, fixtures, translations, documentation, model IDs, code-index provider identifiers, terminal provider identifiers, and other intentional literals should remain unchanged unless replacement provides a clear correctness or type-safety benefit.

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

Targeted migrations: #953, #954, #955, #956, #957, #958, and #959

Acceptance criteria (optional)

• Remaining raw provider literals in production code are reviewed and classified.
• Appropriate internal API-provider comparisons, switch cases, and collections reference canonical identifiers.
• Intentional serialized, external, test, translation, documentation, model-name, and separate-domain literals remain unchanged.
• No API provider identifiers are confused with code-index, embedding, terminal, or other domain-specific provider names.
• Focused regression tests verify representative runtime usage.
• The acceptance criteria of [ENHANCEMENT] Centralize provider identifiers and replace hardcoded provider-name literals #944 are reviewed and satisfied.
• Existing provider-related tests continue to pass with no intended user-facing behavior changes.

Relevant code locations

This is a final audit rather than a predefined mechanical replacement. Re-scan production code after #953–#959, with particular attention to:

• packages/types/src — remaining provider switches, comparisons, maps, and internal collections outside the completed foundational and default-model work.
• src/api — provider dispatch, capability checks, fetchers, and handler-specific comparisons not covered by [ENHANCEMENT] Migrate API handler selection to canonical provider identifiers #955 or [ENHANCEMENT] Migrate model fetching and cache logic to canonical provider identifiers #957.
• src/core — extension workflows not covered by [ENHANCEMENT] Migrate extension-side provider comparisons to canonical identifiers #958.
• src/shared — shared provider-dependent helpers not covered by [ENHANCEMENT] Migrate profile model resolution to canonical provider identifiers #956.
• webview-ui/src — remaining UI provider comparisons not covered by [ENHANCEMENT] Migrate webview provider comparisons to canonical identifiers #959.
• src/services/code-index/service-factory.ts, src/shared/embeddingModels.ts, and webview-ui/src/components/chat/CodeIndexPopover.tsx — classify carefully because these mix names shared with API providers and separate code-index identifiers such as semble and openai-compatible.
• src/integrations/terminal/TerminalRegistry.ts — exclude terminal provider names such as vscode; they are not API provider identifiers.
• Tests and fixtures across the repository — generally retain literal serialized values so compatibility tests continue to detect accidental string changes; replace only when the test is explicitly verifying canonical runtime usage.

Proposed approach (optional)

Search production code for remaining active and retired provider strings after the targeted migrations. Review each occurrence individually, migrate internal API-provider identity comparisons, document intentional exceptions through surrounding context where necessary, and add focused regression coverage.

Trade-offs / risks (optional)

Automated replacement could change external contracts, alter model IDs, reduce fixture readability, or conflate independent provider domains. This cleanup requires individual review of each occurrence and may uncover unrelated inconsistencies that should be reported separately rather than folded into this behavior-preserving refactor.