docs(TODO): Defer §3.4 pre-warm pool to home lab (profiling-dependent optimization)

Move pre-warm pool (maintaining 2 avviati clones) from main §3 backlog to Deferred section.
Rationale: optimization only valuable if profiling shows New-BuildVM+Wait-VMReady is
bottleneck; with 2-min builds ~40% overhead, but ~0% for 10+ min builds.

Update summary table: §3 now shows 3 done, 2 open, 1 deferred (instead of 3 open).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

TODO.md

@@ -31,7 +31,7 @@ _Last updated: 2026-05-10 (post Sprint 7: §1.6/§3.2 done, test plan created)_
 | [ ]   | Gitea Workflow Integration      |    4 |    1 | manca solo §P3 generalizzazione workflow                      |
 | [x]   | §1 Sicurezza & hardening        |    3 |    0 | 1.1, 1.4, 1.6 done; 1.2/1.3/1.5/1.7/1.8 deferred (home lab)   |
 | [x]   | §2 Affidabilità & resilienza    |    7 |    0 | tutto done (2.1-2.7)                                          |
-| [ ]   | §3 Performance & throughput     |    3 |    3 | 3.1/3.2/3.6 done; 3.3/3.4/3.5 backlog                         |
+| [ ]   | §3 Performance & throughput     |    3 |    2 | 3.1/3.2/3.6 done; 3.3/3.5 backlog; 3.4 deferred               |
 | [x]   | §4 Osservabilità & manutenzione |    3 |    0 | 4.1/4.3/4.4 done (4.2 Prometheus, 4.5 Dashboard rimossi)      |
 | [x]   | §5 Qualità codice & test        |    5 |    0 | 5.1/5.2/5.3/5.4/5.5 done                                      |
 | [ ]   | §6 Scalabilità & estensioni     |    0 |    6 | Linux VM, composite action, toolchain Tier-1                  |
@@ -331,16 +331,6 @@ Implementazione disegnata di seguito (sezione "In-VM Git Clone (Ottimizzazione)"
 Vincoli sicurezza PAT: vedi §1.5. Tool prerequisiti (Git, 7-Zip): vedi §6.6.
 Beneficio reale solo per repo > 200 MB con submoduli grandi; misurare prima.
 
-### 3.4 [P3] [ ] Pre-warm pool di cloni
-File: [docs/OPTIMIZATION.md:133-156](docs/OPTIMIZATION.md).
-
-Solo se profilo dimostra che `New-BuildVM` + `Wait-VMReady` (~30-60 s) è il collo di bottiglia.
-Con build di 2 minuti, l'overhead è ~40% — vale lo sforzo. Con build di 10+ minuti, no.
-
-Implementazione minima: scheduled task ogni 5 min mantiene 2 cloni avviati in
-`F:\CI\WarmPool\`; `Invoke-CIJob` fa `Move-Item` di un clone caldo nel suo job dir e parte
-da Phase 4 saltando Phase 2-3.
-
 ### 3.5 [P2] [ ] vCPU/RAM tuning per workload
 File: [docs/OPTIMIZATION.md:82-89](docs/OPTIMIZATION.md), VMX template.
 
@@ -753,6 +743,17 @@ in tutti gli script che lo usano post-migrazione HTTPS.
 **Stato attuale**: Usato in template ma non testato in unit test.
 **Rifiori quando**: Script fallisce su recovery da Credential Manager.
 
+### 3.4 [P3] [ ] Pre-warm pool di cloni
+File: `F:\CI\WarmPool\` (hypothetical); scheduled task via `scripts/Register-CIScheduledTasks.ps1`.
+
+Mantenere 2 cloni avviati in background, pronti per il binding a job. Salta la fase di
+`New-BuildVM + Wait-VMReady` (~30-60s) nel percorso critico. Richiede una VM "watcher" che
+monitora il pool e ricrea cloni dopo uso.
+
+**Stato attuale**: Disegnato ma non implementato. Dipende da §2.1 (IP allocator).
+**Rifiori quando**: Profiling mostra che New-BuildVM+Wait-VMReady è bottleneck >30% nel
+tempo totale di job. Con build >2 minuti, overhead stimato ~40% (rilevante solo per 1-min builds).
+
 ---
 
 ## Suggerimento di sequencing