docs(lxc102): OOM cronic pe 4GB -> 12GB + refresh tabel resurse cluster

Alerta "OOM x2 on pvemini" (09:36) arata procese mici ucise (dbus-daemon,
oom_score_adj:200), dar mesajul kernel dadea containerul real:
oom_memcg=/lxc/102. OOM local containerului, nu presiune de host - pvemini
avea 24Gi disponibili si zram functional.

Baseline masurat cu ZERO sandbox-uri active: ~1.9GB (sbx 863M + claude 317M +
VS Code Remote 450M + docker/tailscale/portainer 205M). Un sandbox real mai
adauga ~1.9GB (containerd-shim) -> plafonul de 4GB era depasit sistematic.
Contoare cumulate: oom_kill 24, 9279 depasiri memory.high, memory.peak fix pe
limita, swap 510/512 epuizat.

Verificat explicit ca sbx NU are memory leak: RSS urca la ~863M la pornire si
se plafoneaza (esantionat la 10s timp de un minut).

Fix: pct set 102 --memory 12288 --swap 4096 (live, fara restart).

Tabelul de resurse din cluster/README.md era vechi (102 aparea ca "coolify
stopped", lipseau 110 si 171, RAM gresit peste tot) - regenerat din pvesh.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

proxmox/cluster/incidents/2026-07-31-lxc110-dns-tailscale-oom.md

@@ -189,3 +189,12 @@ Verificat post-aplicare: ambele `active/running`, porturile 7788 + 7789 deschise
 
 **Legături:** `../../lxc110-moltbot/README.md` · `../../lxc171-claude-agent/README.md`
 (secțiunea „Memorie & OOM" — incidentul zram pvemini 2026-06-24)
+
+> **Al doilea OOM în aceeași zi, alt container, alt mecanism:** LXC 102 (docker/sbx) a
+> generat alertă „OOM x2 on pvemini" la 09:36. Acolo host-ul avea swap funcțional — pur și
+> simplu containerul era subdimensionat (4GB pentru sbx + VS Code + Claude). Ridicat la
+> 12GB. Detalii: `../../lxc102-docker/README.md` → „Memorie".
+>
+> **Numitorul comun al ambelor cazuri:** OOM **local unui cgroup de container**, deși host-ul
+> avea marjă largă, plus victime alese după `oom_score_adj` (procese mici, irelevante) care
+> ascund adevăratul consumator. Primul reflex: citește `oom_memcg=` din mesajul kernel.