docs: record the LinuxRust2404 template, its failure modes and open decisions

- AGENTS.md: LinuxRust2404 reference, plus errors #14-#16 -- deploy --force
  against a powered-on VM, the three distinct causes behind the identical
  "VMware Tools are not running" message, and the orphan snapshot deltas
  --force leaves behind after deleting the .vmsd.
- docs/RUNBOOK.md §16: triage for a Step 7 IP timeout, ordered cheapest check
  first, with a Quick Reference entry.
- docs/RUNBOOK-PhaseC.md: deploy-rust/prepare-rust, the ownership and non-login
  shell constraints on /opt/rust, --then-prepare, and how to route a label to a
  template (a second runner instance, with the verification step).
- TODO.md §2.9: retention run covers only artifacts, logs and IP leases, so it
  warned about low disk while freeing 0.0 GB two runs in a row. Mitigated by
  hand; the automated policy is still blind to what actually weighs.
- TODO.md §6.5: act_runner v1.0.4 -> v2.x evaluated and deferred, with the
  trigger for reopening. v2.1.0 exposes no RUNNER_LABELS either (checked
  against the binary), so the two-runner design is not a stopgap.

TODO.md

@@ -312,6 +312,34 @@ mai rilasciati. Workaround manuale: reset a `{}` con `build-vms/` vuoto.
 cui clone-dir non esiste più in `CloneBaseDir`. Opzionale: allargare il pool
 (es. 201–210) per dare margine oltre parallelism. Aggiungere test.
 
+### 2.9 [P2] [ ] `retention run` non copre backup/template/ISO — APERTO (2026-07-22)
+
+`ci-retention-policy` agisce solo su **artifact, log e lease IP**. Su questo host
+quei tre insiemi pesano 52 KB in tutto, mentre il disco era pieno al 94% per
+`backups/` (195 G), `templates/` (128 G) e `iso/` (69 G) — tutti fuori dal suo
+raggio d'azione.
+
+Sintomo osservato: il timer girava, rilevava meno di 50 GB liberi, dichiarava
+`WARNING: Free space below 50 GB — aggressive retention: 7d` e liberava
+**0.0 GB**, due esecuzioni di fila. L'allarme suonava ma il meccanismo non
+poteva agire su ciò che pesava. Un guardiano che non sorveglia nulla è peggio di
+nessun guardiano: dà l'impressione che il problema sia sotto controllo.
+
+Mitigato il 2026-07-22 (backup svuotati, `--keep-count 1 --exclude WinBuildTest`
+nella unit), ma è una correzione manuale: la policy automatica resta cieca.
+
+**Fix proposto**: estendere `retention run` ai backup (per numero di generazioni
+o per età) e almeno segnalare — non cancellare — ISO e template che superano una
+soglia. In alternativa, se i backup restano governati solo da `--keep-count`,
+far sì che il warning sullo spazio dica **quali** directory pesano, invece di
+lamentarsi senza indicare dove guardare.
+
+**Nota**: `iso/` contiene coppie originale + `.patched` e versioni April
+superate da May (~38 G recuperabili); le `.patched` sono rigenerate da
+`deploy-win`. `templates/WinBuildTest` (41 G, ultimo uso 10 giugno, citato solo
+in `docs/archived/2026-05-10/`) è candidato alla dismissione: escluso dai backup
+ma ancora su disco.
+
 ---
 
 ## 3. Performance & throughput
@@ -518,6 +546,54 @@ Già supportato lato Gitea, basta replicare il setup.
 
 **Deferred**: in un home lab single-host questa funzionalità non serve. Non pianificare.
 
+### 6.5 [P3] [ ] Upgrade act_runner v1.0.4 → v2.x — VALUTATO E RIMANDATO (2026-07-22)
+
+Versione installata: **v1.0.4** (18 mag 2026). Ultima upstream al momento della
+valutazione: **v2.1.0** (16 lug 2026).
+Release: https://gitea.com/gitea/runner/releases
+
+**Decisione: non aggiornare ora.** Il beneficio netto per questo sistema è
+marginale. Valutazione fatta ispezionando il binario v2.1.0 (checksum
+verificato), non solo il changelog.
+
+Cosa **non** cambia — verificato sul binario, non dedotto:
+
+- v2.1.0 esporta al job esattamente le stesse variabili di v1.0.4
+  (`RUNNER_ARCH/TEMP/DEBUG/OS/TOOL_CACHE`), **nessun `RUNNER_LABELS`**. Il
+  `GITEA_RUNNER_LABELS` del changelog v2.1.0 è operator-side: imposta le label
+  del daemon all'avvio, non le espone al workflow. Il routing label → template
+  continua a richiedere un'istanza runner per label (vedi RUNBOOK-PhaseC,
+  sezione `deploy-rust`).
+
+Cosa non ci riguarda: il grosso di v2.x è lavoro su Docker/container
+(credenziali di pull, service container, dind, IPv6). Qui `container.enabled`
+è `false`, host mode puro. Anche l'unico breaking change di v2.0.0
+(`DOCKER_USERNAME`/`DOCKER_PASSWORD` non più impliciti nei pull) è inapplicabile.
+
+Cosa ci riguarderebbe:
+
+| Novità | Valore reale |
+|---|---|
+| Cancellation handling completa (v2.0.0) + reap processi (v1.0.7/1.0.8) | Un job cancellato può lasciare una build VM orfana — ma `ci-cleanup-orphans.timer` gira già ogni 6h |
+| `runner.post_task_script` (v2.0.0) | Aggancerebbe `vm cleanup` dopo ogni task: latenza orfani da ≤6h a immediata |
+| `jobs.<id>.timeout-minutes` / `continue-on-error` (v2.0.0) | Ergonomia workflow |
+| `register --token-file` (v2.1.0) | Già implementato a mano in `scripts/install-rust-runner.sh` |
+
+Schema di configurazione retrocompatibile: il diff v2.1.0 vs il nostro config è
+solo additivo, nessuna chiave rimossa.
+
+**Trigger per riaprire**: quando serve `runner.post_task_script` per azzerare la
+latenza del cleanup orfani, oppure quando la 2.x è matura (era vecchia di 6
+giorni alla valutazione). Non aggiornare "per stare aggiornati".
+
+**Vincolo operativo da ricordare**: i due runner (`act-runner.service` e
+`act-runner-rust.service`) condividono **lo stesso binario**
+`/opt/ci/act_runner/act_runner`. Sostituirlo aggiorna entrambi insieme. Per un
+rollout graduale serve un secondo binario affiancato
+(`act_runner-2.1.0`), l'`ExecStart` del solo servizio rust puntato lì, un job di
+prova su `runs-on: rust-build`, e solo dopo la promozione per il runner
+principale — tenendo v1.0.4 per il rollback.
+
 ### 6.4 [P3] [x] Build matrix nel workflow
 File: [gitea/workflows/build-ns7zip.yml](gitea/workflows/build-ns7zip.yml).