Tech debt: eliminar doble fallback en getProviderType y cachear catálogo de modelos

[Saul-Gomez-J]

Contexto

Tras la implementación de Use Other Providers en Platform Mode (refs cualificadas providerId::modelId), quedaron dos puntos de deuda técnica que conviene abordar cuando los datos legacy crudos dejen de ser relevantes.

---

1. Doble fallback en getProviderType (aiService.ts)

Archivo: src/main/services/aiService.ts — método getProviderType()

Actualmente el método intenta resolver el provider type por dos caminos:

1. Primero llama a resolveModelTarget(modelId) (la vía correcta que soporta refs cualificadas).
2. Si falla, hace un fallback manual buscando por getRawModelId() en los providers de preferencias.

El fallback existe para compatibilidad con sesiones antiguas que guardan model IDs crudos. Una vez que ya no existan datos legacy (o se haga una migración), el bloque catch con la búsqueda manual se puede eliminar, dejando solo la llamada a resolveModelTarget.

Acción: Eliminar el fallback manual cuando se considere que ya no hay datos legacy crudos en producción.

---

2. Catálogo de modelos se recarga en cada mount de useModelSelection

Archivo: src/renderer/hooks/useModelSelection.ts

Cada vez que un componente que usa useModelSelection se monta (ChatPage, cambio de sesión, navegación), se ejecuta loadSelectableModels() que internamente llama a modelService.initialize() y modelService.getAvailableModels().

modelService.initialize() tiene un guard interno (isInitialized), pero getAvailableModels() y getAllProvidersWithSelectedModels() se recomputan cada vez.

En la práctica funciona bien, pero si el usuario navega rápido entre páginas, se generan llamadas redundantes.

Acción sugerida: Mover el catálogo unificado (SelectableModelsResult) a un store de Zustand (o un módulo con caché + invalidación) para que se comparta entre todos los consumidores sin recomputar en cada mount. La invalidación debería dispararse cuando:

• Cambia useOtherProviders
• Cambia appMode
• Se sincronizan modelos de un provider
• Cambian los modelos de Platform

---

Prioridad

Baja. Ambos puntos funcionan correctamente hoy. Son optimizaciones para cuando la base de datos ya no tenga refs legacy y para mejorar rendimiento en navegación frecuente.