Feat: Medical Domain Embeddings Adapter

[iberi22]

Problem

The current EmbeddingsAdapter interface produces generic embeddings that don't capture medical terminology in Spanish. OrionHealth needs embeddings that understand:

• Spanish medical terms (cardiología, nefropatía, etc.)
• Medical abbreviations (TA, FC, SpO2, etc.)
• Domain-specific symptom descriptions

Proposed Solution

Create a MedicalEmbeddingsAdapter that wraps the fallback chain (TFLite → ONNX → Gemini) and:

1. Uses a medical domain fine-tuned embedding model OR
2. Applies post-processing to enhance medical embeddings
3. Supports both English and Spanish medical text

Implementation Plan

1. Create lib/src/embeddings/medical_embeddings_adapter.dart
2. Extend EmbeddingsAdapter interface with medicalNormalized() method
3. Add medical-specific tokenizer that handles abbreviations
4. Add integration with existing FallbackEmbeddingsAdapter chain
5. Export from isar_agent_memory.dart

Reference

OrionHealth consumer: orionhealth/lib/features/local_agent/infrastructure/services/isar_vector_store_service.dart already uses MemoryGraph for RAG. This adapter will improve retrieval quality for medical queries.

See: spec/technical/on-device-ai.md for existing embedding backend docs in cerebro-flutter.

[iberi22]

@jules-ai este issue es ideal para un PR pequeno

[google-labs-jules]

Jules is on it. When finished, you will see another comment and be able to review a PR.

[google-labs-jules]

Ready for a review! A PR has been created.

[iberi22]

@jules-ai CORRECCION SCOPE #38: el MedicalEmbeddingsAdapter no debe contener lógica de negocio médica.

El adapter debe ser GENÉRICO y configurable. En lugar de hardcodear abreviaturas médicas (TA, FC, SpO2), crea un sistema de normalización PLUGGABLE:

`dart
class MedicalEmbeddingsAdapter {
final EmbeddingsAdapter inner;
final TextNormalizationConfig normalizationConfig; // inyectado desde fuera

// Solo normaliza según config, sin hardcodear lógica médica
}
`

Las abreviaturas médicas específicas para España/Latam deben vivir en OrionHealth como configuración, no en el package.

Esto permite que isar_agent_memory sea reutilizable para apps legales, financieras, etc. sin contaminar con lógica médica.