feat(loadtest): load-test tooling + capacity model

boot-labs.js drives the real admin Prepare-Labs endpoint (reusing the
existing session-helper.js from Phase 3A) and records boot time/failure
rate; sample-resources.sh samples real docker stats for running Labs.
capacity-model.js turns measured per-Lab CPU/memory into a recommended/
warning/hard-admission-control concurrency threshold - no concurrency
number is hardcoded as a marketing figure, every input is explicitly
placeholder data until measured against the real host.

Plus deploy/rollback/smoke-test scripts used by the CI/CD and deployment
runbooks. All syntax-checked; validate-compose.sh and capacity-model.js
actually run against real inputs.

infra/scripts/loadtest/report-template.md

@@ -0,0 +1,36 @@
+# RootNode Load Test Report
+
+**Date:** _______
+**Ran against:** [ ] dev laptop  [ ] staging  [ ] production rn-lab-host-01 (real hardware)
+**Host spec (fill in real numbers, do not guess):** ___ cores / ___ threads / ___ GB RAM / ___ storage
+
+> A run against anything other than the real target-class hardware only tells you the code
+> path works, not what production can actually sustain. Say clearly which this is.
+
+## Boot test (`boot-labs.js`)
+
+| Metric | Value |
+|---|---|
+| Requested Lab count | |
+| Successfully running | |
+| Failed | |
+| Failure rate | |
+| Total wall-clock time (concurrent boot) | |
+
+## Resource usage (`sample-resources.sh`)
+
+| Metric | Value |
+|---|---|
+| Peak CPU per Lab (observed) | |
+| Peak memory per Lab (observed) | |
+| Peak disk I/O per Lab (observed) | |
+| Host CPU headroom remaining at peak | |
+| Host memory headroom remaining at peak | |
+
+## Feed into docs/CAPACITY_PLANNING.md
+
+- [ ] Updated `measured_lab_cpu_cores` with the peak CPU figure above
+- [ ] Updated `measured_lab_mem_mb` with the peak memory figure above
+- [ ] Re-ran `infra/scripts/capacity-model.js` and recorded the new recommended-concurrent-Labs number
+
+## Notes / anomalies observed