Record the install trap behind a llama.cpp build that never answers

`llama-server` is a 16 KB launcher against `libllama-server-impl.so`, so a
build installed without a working runpath dies at exec and reaches the phone
as a model that never became ready. `GNUInstallDirs` picks `lib64` on some
distributions while the recorded runpath says `lib`, which is how the two
flags come apart.

.claude/skills/ai-app-rigs/SKILL.md

@@ -182,7 +182,19 @@ beside the ordinary `llama-cpp`. It is what exercises that mechanism at all,
 and it serves `prism-ml/Ternary-Bonsai-2-27B-gguf` -- ternary packings stock
 llama.cpp rejects as unknown types. Rebuild it with
 `cmake -B build -DCMAKE_BUILD_TYPE=Release -DGGML_VULKAN=ON
--DCMAKE_INSTALL_RPATH='$ORIGIN/../lib'`, about six minutes at `-j8`.
+-DCMAKE_INSTALL_LIBDIR=lib -DCMAKE_INSTALL_RPATH='$ORIGIN/../lib'`, about six
+minutes at `-j8`.
+
+**Both of those install flags are load-bearing, and the failure is a session
+that never becomes ready.** `llama-server` is a 16 KB launcher against
+`libllama-server-impl.so`, so a build whose libraries it cannot find dies at
+`exec` with `error while loading shared libraries` -- which reaches the phone
+as the model never answering. The runpath has to be set, *and* the libraries
+have to be where it points: `GNUInstallDirs` chooses `lib64` on some
+distributions (Gentoo's amd64 profiles among them) while the runpath above
+says `lib`. `readelf -d bin/llama-server | grep RUNPATH` and
+`ldd bin/llama-server | grep 'not found'` are the two-second check after any
+install here.
 
 **Which Bonsai packing runs on the GPU is the backend's question, not the
 model's.** Measured 2026-09-21 with `llama-bench -p 512 -n 64 -r 2 -fa 1