revert(m1): zdjecie NODE_TYPE=lte_node na SOLARII i VPS po wdrozeniu R1

Warunek zdjecia M1 brzmial "R1 (prune filtrowany po restart policy / labelu
compose) wdrozony na tym nodzie". Zweryfikowane bezposrednio w kodzie dzialajacych
kontenerow, nie po datach deployu:

  SOLARIA  md5(/app/src/node_agent.py) = c9ac64e10b42b3e0ed9e4c168579bfaa,
           identyczny z origin/master.
  VPS      rozni sie od origin/master wylacznie trescia komentarzy (5 linii
           `docs/backlog.md` vs `kb/phases/backlog.md`, skutek migracji sciezek
           w 9128530) — zero roznic funkcjonalnych.

Na obu nodach `_prune_stopped_containers` jest obecny (te same numery linii:
635/700/717/725), a jedyne wystapienia `containers.prune()` to tekst docstringa
i komentarza — brak wykonywalnego niefiltrowanego prune. Sprawdzone dodatkowo,
ze scripts/monitor/health-monitor.sh (ktory nadal ma niefiltrowane
`docker container prune -f` — R1 objelo tylko node_agent.py) nie jest wpiety w
zaden crontab ani timer na SOLARII i VPS, wiec node-agent byl faktycznie jedynym
zrodlem prune i cleanup byl na obu nodach realnie wylaczony.

SOLARIA: przywrocone jawne NODE_TYPE=ai_node — stan sprzed M1 (1cd6401),
zgodnie z konwencja pozostalych hostow, ktore wszystkie ustawiaja NODE_TYPE
jawnie (piha/lustro sd_card, chelsty-infra lte_node). solaria jest w AI_NODES,
wiec default dalby to samo, ale jawny wpis nie zalezy od hostname'u.

VPS: linia usunieta w calosci wraz z komentarzem TEMPORARY — dokladny stan
sprzed 11f3f80, gdzie NODE_TYPE nie bylo ustawione wcale. Potwierdzone, ze
default daje `standard`, nie None: base compose przekazuje `NODE_TYPE=${NODE_TYPE:-}`,
czyli pusty string, ktory jest falsy, wiec _resolve_node_type() schodzi do
rozpoznania po nazwie, a `vps` nie nalezy do LTE_NODES/SD_CARD_NODES/AI_NODES.
Sprawdzone na zlozonym `docker compose config` (NODE_TYPE: "") i uruchomieniem
_resolve_node_type() -> 'standard'. Rotacja filesystemu control-plane jest
bramkowana node_name == VPS_NODE_NAME, nie node_type, wiec dziala niezaleznie.

UWAGA DO DEPLOYU: na obu nodach brak /opt/homelab/state/last-docker-cleanup,
a przy braku markera _cleanup_rate_ok() zwraca True — pierwszy cleanup pojdzie
w pierwszym cyklu po restarcie (<=60 s), nie po 24 h jak na LUSTRO.
W chwili sprawdzenia zero kontenerow `exited` na obu nodach, wiec galaz
kontenerowa nie ma czego usunac; do sprzatniecia sa 4 dangling images na SOLARII
(~553 MB) i 1 na VPS (395 MB) plus build cache. humanai-mailer i humanai-landing
maja restart=unless-stopped, wiec sa chronione pierwsza galezia filtra R1 nawet
gdyby zostaly zatrzymane.

node-agent: 70 passed.

Refs docs/incidents/2026-07-30-ollama-solaria-vanish.md (§7, M1),
docs/sessions/2026-08-06.md (follow-up #5)

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

hosts/solaria/runtime/node-agent/docker-compose.override.yml

@@ -1,16 +1,3 @@
-# MITYGACJA TYMCZASOWA (M1) — założona 2026-08-04.
-# NODE_TYPE=lte_node wyłącza run_safe_cleanup() (niefiltrowany
-# `docker container prune`) na czas backfillu embed (faza mailowa KB).
-# Incydent: kb/incidents/2026-07-30-ollama-solaria-vanish.md (§7, M1).
-# Bez tego każdy zatrzymany kontener na SOLARII znika w ≤60 s — również taki
-# z `restart: unless-stopped`, zatrzymany świadomie przez operatora.
-# Warunek zdjęcia: R1 (filtrowanie prune po restart policy / labelu compose)
-# wdrożony na tym nodzie — R1–R3 są w toku po stronie subsystemu A.
-# Po zdjęciu przywrócić: NODE_TYPE=ai_node.
-# Zakres wyłączenia: `lte_node` pomija CAŁY cleanup, więc na czas mitygacji
-# nie są też sprzątane dangling images ani build cache — pilnować miejsca
-# na dysku. Monitoring, eventy i dispatch akcji działają bez zmian
-# (self.node_type jest czytane wyłącznie w run_safe_cleanup i dwóch liniach logu).
 services:
   node-agent:
     # Docker GID on SOLARIA is 996 (not the Debian default 999 the base compose
@@ -23,7 +10,11 @@ services:
       - "996"  # host docker gid, verified 2026-07-30 (getent group docker → 996)
     environment:
       - NODE_NAME=solaria
-      - NODE_TYPE=lte_node   # M1 (2026-08-04) — było: ai_node; przywrócić po R1
+      # ai_node = dangling images + kontenery + build cache, ale NIGDY
+      # `image prune -a` (skasowałoby obrazy runtime Ollamy). Ustawione jawnie,
+      # zgodnie z konwencją pozostałych hostów, mimo że solaria jest w AI_NODES
+      # w node_agent.py i default dałby to samo.
+      - NODE_TYPE=ai_node
       - VPS_EVENTS_HOST=100.95.58.48
       - VPS_EVENTS_USER=oskar
       - VPS_EVENTS_PATH=/opt/homelab/events

hosts/vps/runtime/node-agent/docker-compose.override.yml

@@ -3,18 +3,11 @@ services:
     environment:
       - NODE_NAME=vps
       - CHECK_INTERVAL=60
-      # TEMPORARY mitigation (M1) for the unfiltered-prune incident
+      # No NODE_TYPE here on purpose: `vps` is in none of node_agent.py's
-      # (kb/incidents/2026-07-30-ollama-solaria-vanish.md §7). node-agent runs
+      # LTE_NODES / SD_CARD_NODES / AI_NODES sets, so _resolve_node_type() falls
-      # `docker container prune()` with NO filters every CHECK_INTERVAL, and the
+      # through to "standard" — dangling images + stopped containers + build
-      # Docker API removes EVERY non-running container regardless of restart
+      # cache, plus the control-plane filesystem rotation (that one is gated on
-      # policy or compose labels — this already destroyed ollama@solaria. On VPS
+      # node_name == VPS_NODE_NAME, not on node_type). This is the pre-M1 state.
-      # the loss is worse: humanai-mailer and humanai-landing have no compose
-      # definition in this repo, so a pruned container cannot be recreated.
-      # node_type is read ONLY by run_safe_cleanup() (plus two log lines), so
-      # lte_node disables cleanup and nothing else — monitoring, event shipping
-      # and action dispatch keep working.
-      # REMOVE once R1 (explicit-enumeration prune) is deployed to VPS.
-      - NODE_TYPE=lte_node
     # host network mode: node-agent on VPS shares the host's network namespace
     # so that localhost:18180 resolves to the control-plane's exposed port.
     # Without this, localhost inside the container is the container's own loopback