fix(rag): ubatch=2048 pour llama-embed + retry rag-ingest + nettoie defaults rag

L'instance llama-embed (:1238) tournait avec l'ubatch llama.cpp par défaut (512).
En mode --embeddings + pooling, toute l'entrée doit tenir dans un seul ubatch →
tout chunk > 512 tokens échouait en HTTP 500 « input too large to process.
increase the physical batch size ». ~46 chunks du RAG (CHUNK_MAX=2000 chars ≈
700 tokens) n'étaient pas indexés.

- llama_server : ajoute llama_embed_ubatch_size (2048 = ctx) + flags
  --batch-size/--ubatch-size dans le template llama-embed.service.
- rag-ingest : retry (5×, backoff) sur erreurs transitoires 5xx/réseau de l'embed.
- rag/defaults : aligne embed_url/embed_model sur nomic :1238 (étaient des vars
  mortes pointant encore qwen3-8b :1234 — trompeuses).

Résultat : ré-ingestion 436/436 chunks, 0 erreur.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

ansible/roles/llama_server/defaults/main.yml

@@ -23,6 +23,11 @@ llama_embed_model_path: ""          # chemin GGUF sur /mnt/models (NFS)
 llama_embed_model_url: ""           # URL de téléchargement (HuggingFace) — get_url si absent
 llama_embed_model_alias: "nomic-embed-text"
 llama_embed_ctx_size: 2048
+# Batch physique (ubatch) = contexte : en mode --embeddings avec pooling, toute l'entrée doit
+# tenir dans UN seul ubatch. Le défaut llama.cpp (512) fait échouer en HTTP 500 tout chunk
+# > 512 tokens (« input too large to process. increase the physical batch size ») — c'est ce
+# qui faisait rater ~46 chunks du RAG (CHUNK_MAX=2000 chars ≈ 700 tokens). Aligné sur ctx-size.
+llama_embed_ubatch_size: 2048
 # CPU par défaut (0 couche GPU). nomic-embed-text est minuscule (137M) → ~100 ms en CPU,
 # DÉTERMINISTE. Sur GPU (99) il partage la RX 6700XT avec le chat qwen3-8b (:1234) et tombe
 # dans la file derrière une génération → latence BIMODALE (16 ms ou 9-12 s, voire timeout) →