v0.52.0: operator-opt-in CPU/RAM cap for the provisioned guest (-cores/-memory)

New -cores N / -memory M (MiB) flags for --selftest=bring-up|provision (0 = keep
golden default), flowed through bringUpSizing into reconcile.BringUpSpec so the
existing buildBringUpConfig emits cores/memory into the pre-start config PUT (the
cap lands before first boot). No engine change. New pure-function test
TestBuildBringUpConfig_ResourceCaps asserts the set + omit-when-zero cases
(red-proof run + reverted). go build/vet/test clean.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

CHANGELOG.md

@@ -1,3 +1,29 @@
+## v0.52.0 — operator-opt-in CPU/RAM cap for the provisioned guest (`-cores` / `-memory`) (2026-07-01)
+
+Colleague-safety batch #3. So a trial appliance guest on a colleague's SHARED production Proxmox does
+not pressure his existing guests, the operator can now cap the guest's CPU cores + RAM **at provision
+time, before the guest's first boot** (the peak container-pull moment). Pure CLI→spec plumbing — the
+reconcile engine already applied the cap; this only wires the flags to it.
+
+- **`cmd/felhom-agent/main.go`:** new `-cores N` / `-memory M` (MiB) flags for
+  `--selftest=bring-up|provision` (0 = keep the golden's baked size). They flow through `bringUpSizing`
+  (now carries `Cores`/`MemoryMB`) into the `reconcile.BringUpSpec{Cores,MemoryMB}` built by BOTH
+  `runSelftestBringUp` and `runSelftestProvision`. The `-selftest` usage string documents them.
+- **No engine change.** `internal/reconcile/bringup.go` already carries `BringUpSpec.Cores/MemoryMB`
+  (0 = leave as restored) and `buildBringUpConfig` already emits `cores`/`memory` into the SAME
+  coalesced config PUT as the identity reset — which runs BEFORE `e.api.Start`, so the cap lands
+  pre-boot. Rejected the `pct set`-post-provision alternative (runs after boot = an uncapped window;
+  bypasses the token/audit; second config source of truth).
+- **Omit-when-zero guarantee:** an unset cap (0) emits NEITHER `cores` NOR `memory`, so an uncapped
+  provision keeps the golden defaults (no regression for the normal single-purpose box) and can never
+  shrink the guest to 0 cores. New pure-function test `TestBuildBringUpConfig_ResourceCaps` asserts
+  both the set (`cores=2`,`memory=4096`) and the absent-when-unset cases; a red-proof (unconditional
+  emit) was run and confirmed to fail the omit assertion, then reverted.
+- **Deploy dependency:** a FRESH host-install `--cores`/`--memory` (felhom.eu script v1.4.0) requires
+  the hub artifact manifest to serve **agent ≥ v0.52.0**, else the old agent rejects the unknown flag.
+  The flags are opt-in, so nobody hits this until they intentionally cap.
+- `go build` / `go vet` / `go test ./...` clean.
+
 ## v0.51.0 — local vzdump retention default (`--prune-backups keep-last=3`) (2026-06-30)
 
 The PREVENTIVE counterpart to the hub's host_disk + storage_fill detectors: the agent's periodic local