Simplification radicale : moteur pris de l'image officielle llama.cpp

Plus aucune compilation CUDA : le runtime part de
ghcr.io/ggml-org/llama.cpp:server-cuda (llama-server précompilé et maintenu
par l'équipe amont, backends .so chargés dynamiquement, archs GPU courantes,
repli CPU fonctionnel). Le build complet passe de ~40 min à ~4 min et tous
les pièges du build CUDA sans GPU (stubs libcuda, espace disque du runner,
choix des architectures) disparaissent.

- Dockerfile : 2 étapes (Go + image officielle), build-arg LLAMACPP_IMAGE
  pour épingler une version ou passer en CPU/Vulkan
- entrypoint : BIN=/app/llama-server
- workflow GHCR : purge disque et CUDA_ARCHS supprimés, cache max
- compose/.env/README à l'avenant

Validé : build 3 min 55, UI HTTP 200, healthcheck healthy, superviseur PID
OK, llama-server démarre (repli CPU) et n'échoue que sur un modèle factice.

docker-entrypoint.sh

@@ -6,9 +6,10 @@ set -eu
 : "${LOKI_HOME:=/data}"
 mkdir -p "$LOKI_HOME"
 
-# Le chemin du moteur est imposé par l'image : on le (re)pose à chaque boot,
+# Le chemin du moteur est imposé par l'image (llama-server précompilé de
+# l'image officielle llama.cpp, dans /app) : on le (re)pose à chaque boot,
 # une mise à jour de l'image ne doit pas laisser un BIN obsolète en base.
-loki config set "BIN=/opt/llama.cpp/llama-server"
+loki config set "BIN=/app/llama-server"
 
 # Les autres clés ne sont semées QUE si absentes : ce que l'utilisateur règle
 # ensuite dans l'UI (modèle, contexte…) est conservé d'un redémarrage à l'autre.