fix(gpu): débloque make apply-gpu — repo amdgpu rhel9.7 + pin commit llama.cpp

Le `dnf upgrade` du rôle common avait bumpé gpu-01 en AlmaLinux 9.8, mais
repo.radeon.com ne publie pas latest/rhel/9.8 (ni 9.5) — seulement 9.4/9.6/9.7.
`make apply-gpu` échouait alors dès `common` sur « Cannot download repomd.xml »
pour le repo amdgpu.

- rocm_rhel_version 9.4 → 9.7 (dernière mineure publiée par radeon) + piège
  documenté dans le README rocm (avec workaround live /etc/dnf/vars/amdgpudistro).
- Pin llama_server_commit au commit construit sur g01 : sans pin le rôle clonait
  HEAD → rebuild (~15 min) + restart GPU non déterministe à chaque apply.
- Réconciliation du drop-in llama-embed (ubatch 2048) dans l'unit rendu par le
  rôle (apply ciblé) ; drop-in temporaire supprimé. RAG validé (rag-query OK).
- Doc : etat-cluster + journal 2026-06-22 mis à jour.

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

ansible/roles/llama_server/README.md

@@ -4,7 +4,10 @@ Compile llama.cpp (backend HIP/ROCm) et déploie le service **llama-server GPU**
 
 ## Ce que fait le rôle
 
-- Clone + build llama.cpp (cmake HIP, `gfx1030`) — build seulement si le binaire est absent
+- Clone + build llama.cpp (cmake HIP, `gfx1030`) — build seulement si le binaire est absent.
+  Le commit est **pinné** (`llama_server_commit`) : sans pin, le clone tirait `HEAD` et un
+  `make apply-gpu` pouvait déclencher un rebuild (~15 min) + restart GPU non déterministe. Pour
+  monter de version : bumper le SHA dans `defaults/main.yml`, puis l'apply rebuild de façon voulue.
 - Service systemd `llama-server` : modèle GGUF depuis `/mnt/models` (NFS), `:1234`
 - Embeddings activés (`--embeddings`, pooling mean)
 - Ouvre le port dans le firewall, désactive l'ancien service lm-studio