v0.101.0 — R-82: a leaked restore-test scratch can no longer auto-start

CORRECTION: I earlier reported that the restore-test would boot a scratch guest
with the live guest's MAC/static island IP/hostname and break the control
plane. That was WRONG — RunRestoreTest step 2 link-downs EVERY interface
(withLinkDown, unit-tested) before the guest is ever started. The design
already handled it.

The real, narrower hazard: a restore that fails BEFORE step 2 (what the v0.100.0
wait bug caused) leaves a scratch holding the SOURCE guest's config verbatim,
including onboot:1. If teardown also fails (403 missing VM.Allocate — PVE
associates the pool only at restore completion), a host reboot would start that
leaked clone alongside the original with NICs up.

- proxmox.RestoreLXCOptions.ConfigOverrides: guest-config params applied AT
  RESTORE TIME.
- The restore-test passes onboot=0 — at restore time, not after, because
  'after' is exactly the path that leaks.

NOT changed: the link-down step (already correct, the primary defence); the
agent's Proxmox privileges (widening VM.Allocate to /vms would remove the
accidental guard that stopped a destructive mid-restore teardown).

restore_test_cadence_seconds was set to -1 on demo-felhom under the mistaken
reading; re-enabled.

Red-proof observed; full suite green (29 packages).

CHANGELOG.md

@@ -1,3 +1,40 @@
+## v0.101.0 — R-82: a leaked restore-test scratch can no longer auto-start (2026-07-26)
+
+**Correction first, because it matters more than the fix.** I reported earlier in this arc that the
+restore-test would boot a scratch guest carrying the live guest's MAC, static island IP and
+hostname, and so would break the controller→agent link. **That was WRONG.** `RunRestoreTest` step 2
+link-downs **every** interface (`withLinkDown`, unit-tested) BEFORE the guest is ever started, so on
+the normal path there is no L2/IP conflict. The design already handled it.
+
+What is real is narrower. A restore that fails **before** step 2 — exactly what the v0.100.0 wait
+bug caused — leaves a scratch guest holding the SOURCE guest's config verbatim, including
+`onboot: 1`. If teardown then also fails (it did: `403 … missing privilege VM.Allocate`, because PVE
+associates the pool only at restore COMPLETION), the leaked guest survives and **a host reboot would
+start it** alongside the original, NICs up, same MAC, same `169.254.253.2/30`.
+
+So the hazard needed three things to line up, and it did, once, on demo-felhom.
+
+### Changed
+- **`proxmox.RestoreLXCOptions.ConfigOverrides`** — arbitrary guest-config params applied AT RESTORE
+  TIME, for settings that must hold from the instant the guest exists.
+- **The restore-test passes `onboot=0`.** At restore time, not after: "after" is precisely the path
+  that leaks. A leaked scratch is now inert across a host reboot even with its NICs still up.
+
+### NOT changed
+- The link-down step. It was already correct and is the primary defence; this is depth behind it.
+- The agent's Proxmox privileges. It still cannot tear down a scratch until the restore completes.
+  Widening `VM.Allocate` to `/vms` would remove the accidental guard that stopped a destructive
+  mid-restore teardown — the wrong trade. With the v0.100.0 timeout fix the teardown no longer fires
+  mid-restore.
+
+### Operational
+`restore_test_cadence_seconds` was set to `-1` on demo-felhom as a stopgap under the mistaken
+reading above. **Re-enabled** — the scheduled restore-test is safe and always was.
+
+### Tests
+`TestRestoreTest_RestoreSetsOnbootZero`; red-proof observed (removing the override yields
+`got "" (map[string]string(nil))`). Full suite green (29 packages).
+
 ## v0.100.0 — R-82: the restore tier comes from the ARCHIVE, not the configured target (2026-07-26)
 
 **Found by the first real PBS restore round-trip (2026-07-26), not by review.** Restoring