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.

AGENTS.md

@@ -567,8 +567,10 @@ linked runbooks.
   stale token is not enough, and `podman system migrate` segfaults in
   `teardownNetworkBackend`. Repair: **reboot** (`/run/user` clears and all 28
   quadlets return on their own — check `Linger=yes` and `WantedBy=default.target`
-  first). Observed trigger 2026-09-16: memory pressure from an iGPU run that
-  committed 116 of the host's 121 GiB.
+  first). Seen 2026-09-16, hours into heavy GPU work on the same host — but the
+  trigger is NOT established (`journalctl -k` recorded no OOM kill; the kernel
+  had no other word on it). Treat the pause process as host state that can die
+  for its own reasons, and reach for the reboot when it does.
 - **A container cannot reach a `Network=host` service at the host's LAN IP.**
   netavark DNATs *published* ports only: from a bridge container
   `192.168.0.143:<published>` answers while `192.168.0.143:<host bind>` and the