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.

docs/RUNBOOK.md

@@ -250,6 +250,7 @@ Estimated time: 2-4 hours including Windows Update.
 | Template corrupt    | Remove `*.lck` files; if persistent, restore from `F:\CI\Backups\` |
 | Snapshot missing    | `vmrun listSnapshots <vmx>`; update `GITEA_CI_SNAPSHOT_NAME`       |
 | IP collision        | `Remove-Item F:\CI\State\ip-leases\*.lease`; lower `capacity`      |
+| Step 7: no guest IP | `ps -eo pid,lstart,args \| grep vmware-vmx` — see §16               |
 
 ---
 
@@ -868,3 +869,92 @@ This is **optional** — the default boots-to-Linux behaviour is intentional so
 the machine comes back as the Linux CI host after any unattended reboot
 (power-loss, kernel update). Leave it as-is unless Windows becomes the daily
 driver.
+
+---
+
+## 16. `deploy-*` step 7 in timeout — nessun IP dal guest
+
+**Sintomo.** `deploy-linux` / `deploy-rust` cicla su
+`... waiting for guest IP (open-vm-tools) ...` per 10 minuti e chiude con
+`Error: [Deploy Step 7] Timed out waiting for guest IP.` Interrogando a mano:
+
+```
+$ vmrun -T ws getGuestIPAddress <vmx>
+Error: The VMware Tools are not running in the virtual machine
+```
+
+Quel messaggio è ambiguo: esce identico sia quando il guest **non ha** un IP,
+sia quando ce l'ha ma i Tools non rispondono. Tre cause distinte, in ordine di
+verifica dal più veloce al più lento.
+
+### 16.1 Collisione con una VM già accesa (la più insidiosa)
+
+Succede quando si lancia `deploy-* --force` mentre la stessa VMX è in uso —
+tipicamente un `prepare-*` ancora in corso. Occorso il 2026-07-22 su
+`LinuxRust2404`.
+
+```bash
+ps -eo pid,lstart,etime,args | grep vmware-vmx | grep -v grep
+```
+
+Se il `vmware-vmx` vivo è **più vecchio** del deploy appena lanciato, è questo
+il caso: il deploy ha cancellato il `.vmdk.lck` della VM viva credendolo stale,
+ha riscritto il VMDK base sotto il guest in esecuzione, e il suo power-on è
+morto subito perché la VMX era occupata. Il controllo
+`[OK] VM appears in vmrun list` **non protegge**: vede l'istanza vecchia.
+
+Recupero:
+
+```bash
+sudo -u ci-runner vmrun -T ws stop <vmx> hard
+sudo rm -f <vm-dir>/<disk>-00000*.vmdk     # delta orfani, vedi 16.4
+sudo -u ci-runner vmrun -T ws list          # deve dire 0
+# poi rilanciare il deploy, con nient'altro in esecuzione sulla stessa VMX
+```
+
+Non risolvere con un retry: riavviare una VM già corrotta ripete il fallimento
+con la causa ormai illeggibile.
+
+### 16.2 DHCP dell'host incastrato
+
+```bash
+ip -4 addr show vmnet8        # atteso: inet 192.168.79.1/24
+ps -ef | grep vmnet-dhcpd     # atteso: due istanze (vmnet1 + vmnet8)
+```
+
+Se `vmnet8` manca o `vmnet-dhcpd` non c'è:
+
+```bash
+sudo systemctl restart vmware-networks     # oppure vmware-host.service
+```
+
+### 16.3 Guest senza lease, oppure Tools non ancora pronti
+
+```bash
+grep -A1 '^lease' /etc/vmware/vmnet8/dhcpd/dhcpd.leases | tail -20
+ip neigh show dev vmnet8
+```
+
+Se compare un lease per il MAC della VM, **il guest è vivo e ha rete**: mancano
+solo i Tools. Sondare direttamente la porta 22 invece di aspettare
+`getGuestIPAddress`:
+
+```bash
+timeout 5 bash -c 'cat < /dev/null > /dev/tcp/<ip>/22' && echo "SSH aperta"
+```
+
+Se invece non c'è nessun lease e le due verifiche precedenti sono pulite, il
+guest non sta completando il boot: cloud-init fallito o immagine corrotta.
+
+### 16.4 Delta di snapshot orfani
+
+`deploy-*` cancella `<vm>.vmsd` per evitare l'errore di resize sulla catena
+snapshot, ma **non** rimuove i file delta `<disk>-00000N.vmdk`. Restano con un
+`parentCID` che non corrisponde più al base ricreato. Sono innocui — la VMX
+punta al base, riconoscibile da `parentCID=ffffffff` — ma confondono la
+diagnosi. Verifica della catena:
+
+```bash
+grep -i 'scsi0:0.fileName' <vmx>
+head -c 2000 <disk>.vmdk | strings | grep -E '^CID|parentCID'
+```