[F2-07] Interfaz de proveedores de IA, registro y suite de contrato #32

Fase: F2 · Tamaño: M · Depende de: #25 (F2-01), #28 (F2-06)
Decisiones: D-03 y D-17 en #1

Objetivo

Que el usuario pueda elegir proveedor y modelo por capacidad, y que añadir un proveedor sea implementar una carpeta y pasar una suite de tests común.

Alcance

• apps/server/src/core/providers/:
  • Tipos Capability = 'text' | 'tts' | 'music' | 'image' (la capacidad video se declara pero no se implementa en v1).
  • ModelInfo con las restricciones de cada modelo: salida estructurada (json-schema | tool-call | prompt-only), idiomas, máximo de caracteres TTS, relaciones de aspecto de imagen, duración máxima de música.
  • Precio estimado por modelo (por 1M tokens, por 1K caracteres TTS, por imagen, por minuto de música) para el estimador de coste. Es un dato de catálogo con fecha de revisión.
  • Adaptadores: TextAdapter.generateJson, TtsAdapter.listVoices/synthesize, MusicAdapter.generate, ImageAdapter.generate.
  • ProviderCtx { apiKey, signal, log }: la clave llega en cada llamada, nunca desde process.env.
  • registry.get(providerId), registry.list().
• El catálogo de modelos es un dato (JSON/TS), no código.
• TextAdapter.generateJson valida siempre con zod y hace un único reintento de reparación si falla.
• Suite de contrato reutilizable: cada adaptador se ejecuta contra respuestas grabadas (fixtures).

Criterios de aceptación

• pnpm --filter server test providers ejecuta la suite de contrato para cada proveedor registrado.
• Test: un adaptador que devuelve JSON inválido una vez y válido después pasa; dos veces inválido → ProviderError('invalid_request').
• grep -rn "process.env" apps/server/src/core/providers no devuelve nada.
• Todo modelo del catálogo tiene precio y priceReviewedAt (test).