docs: the pause-process trigger is unproven — say so, everywhere

I had written 'memory pressure from the 116 GiB iGPU runs' as the cause of the
pause-process death. journalctl -k records no OOM kill for that window and the
kernel says nothing else about it, so the claim was a guess wearing a finding's
clothes — in AGENTS.md, the x4 note, and the log. All three now state the
trigger is not established, and the note's 'co-tenants' patience' bullet no
longer asserts that causality either. AGENTS.md also gains the real lesson:
journalctl -k is the check, and an unknown cause does not need a story.

serverAppConfigs-docs/LLM/x4-pair-experiment.md

@@ -210,11 +210,13 @@ distinguishes a real split from a mislabelled sweep.
   3.2 GB in a few minutes, no error, no exit. Use `llama-server` for scripted
   runs, or `-st/--single-turn` with llama-cli. (`-no-cnv` is not a flag in this
   build.)
-- **A killed rootless podman pause process takes the whole host's container
-  management down.** After the experiment the pause process was gone (plausible
-  cause: memory pressure from the 116 GiB iGPU runs), and every `podman` command
-  for the user failed with `invalid internal status … could not find any running
-  process`. `podman system migrate` — the remedy podman itself names — **panics**
+- **A dead rootless podman pause process takes the whole host's container
+  management down.** After the experiment the pause process was gone and every
+  `podman` command for the user failed with `invalid internal status … could not
+  find any running process`. The trigger is **not** established: `journalctl -k`
+  holds no OOM kill for that window, so the tempting reading ("the 116 GiB runs
+  squeezed it out") is a guess and is recorded as one.
+  `podman system migrate` — the remedy podman itself names — **panics**
   in 5.7.0 (`teardownNetworkBackend` nil deref). The rootless netns that holds
   podman's bridge addresses is gone with it, so `aardvark-dns` cannot bind
   `10.89.x.1:53` and *every* container start fails. Repair: reboot (it clears
@@ -226,8 +228,10 @@ distinguishes a real split from a mislabelled sweep.
   same evening when `hermes.franksdank.cloud` 502'd — fixed in the Caddyfile and
   guarded by a strengthened seam (`tests/hermes_webui.bats`).
 - **The memory budget includes the co-tenants' patience.** The iGPU runs held
-  116 of 121 GiB; the pause-process death above is the visible cost of running a
-  model that big on a host that also serves.
+  116 of the host's 121 GiB for minutes at a time. Nothing in the kernel log
+  proves damage came of it, but running a model that big on a host that also
+  serves ~28 containers is asking the question — do it in a window, not
+  alongside.
 
 ## Conclusion