refactor(renderer): ProviderSettings v2 migration + ClassifiableModel compat layer

[jidan745le]

What this PR does

Before this PR:

• ProviderSettings UI reads all data from Redux store using v1 types (@renderer/types Model/Provider)
• config/models/ classification functions only accept v1 Model, requiring as unknown as V1Model casts from v2 callers
• vision.ts and websearch.ts synchronously read Redux store via getProviderByModel to determine provider protocol type

After this PR:

• ProviderSettings full UI chain (22 files) consumes v2 DataApi (SQLite + SWR) via useProvider(), useModels(), useProviderApiKeys()
• All config/models/ classification functions accept ClassifiableModel (v1/v2 compatible interface) — zero casts needed from either side
• vision.ts/websearch.ts use model's own endpointTypes field instead of Redux lookup — config/models/ is now pure functions with zero store dependency
• Shared components (ModelIdWithTags, FreeTrialModelTag, getModelLogo, ProviderAvatar) accept both v1 and v2 Model

Fixes #N/A

Why we need it and why it was done in this way

The following tradeoffs were made:

• Introduced ClassifiableModel as a transitional compatibility interface rather than changing all 30+ v1 callers at once. This allows incremental page-by-page migration while keeping everything working.
• normalizeEndpointType bridges v1 endpoint names ("openai-response") to v2 ("openai-responses") so callers only need to use v2 constants.
• getLowerBaseModelName auto-strips :: prefix from v2 UniqueModelIds to maintain regex matching correctness.

The following alternatives were considered:

• Changing all callers to v2 at once — rejected as too large a blast radius for one PR
• Keeping getProviderByModel Redux dependency — rejected because it makes config/models/ impure and fails silently for v2 Models (provider-specific checks return wrong results)

Breaking changes

None. All changes are backward-compatible:

• v1 callers continue to pass v1 Model/Provider without any changes
• v2 callers pass v2 types directly without casts
• ClassifiableModel is a structural supertype that both satisfy

Special notes for your reviewer

Commit structure (2 commits):

1. refactor(config/models): introduce ClassifiableModel v1/v2 compat layer — infrastructure: ClassifiableModel interface, helpers, all config/models functions widened, shared components widened
2. refactor(ProviderSettings): migrate full UI chain to v2 DataApi — consumer: ProviderSettings pages, popups, health check, API key management all switched to v2 DataApi

4 remaining as unknown as V1Model casts are all at the AiProvider (aiCore) boundary — checkApi/checkModel/fetchModels. These will be removed when aiCore supports v2 types.

ClassifiableModel is a transitional layer, not a permanent type. Exit plan documented in docs/provider-registry-renderer-pr.md. When all pages migrate to v2 and aiCore supports v2 types, ClassifiableModel and all its helpers will be deleted in favor of direct v2 Model usage.

Checklist

• PR: The PR description is expressive enough and will help future contributors
• Code: Write code that humans can understand and Keep it simple
• Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
• Upgrade: Impact of this change on upgrade flows was considered and addressed if required
• Documentation: A user-guide update was considered and is present (link) or not required.
• Self-review: I have reviewed my own code before requesting review from others

Release note

NONE