Add pve-test.sweet.home as a second Proxmox target

pve1.sweet.home is production; scripts/env.sh now also defines
PVE_TEST_HOST for a separate sandbox node, individually targetable via
--node/PROXMOX_HOST. Tooling defaults are unchanged (still pve1) -- the
new restriction (Claude defaults to pve-test unless explicitly told to
use pve1) is documented as policy in CLAUDE.md, not enforced in the
scripts.

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

README.md

@@ -36,6 +36,11 @@ Check the Proxmox node itself, or `/etc/flake-target` on a running host (see
 below), if you need to know what's really out there right now.
 `scripts/proxmox/create-proxmox-resource.sh`'s duplicate-host guard works the same
 way: it checks the Proxmox node directly rather than any file here.
+Real, production deployments live on `pve1.sweet.home`; there's a second
+node, `pve-test.sweet.home`, set aside purely for scratch/test resources —
+see `scripts/env.sh` (`PVE1_HOST` / `PVE_TEST_HOST`, and the
+`--node`/`PROXMOX_HOST` targeting they feed into) and CLAUDE.md's Proxmox
+section for which is which.
 
 Each buildtype's `hosts/<name>/host.nix` carries the per-machine identity
 (hostname, hostId, per-machine secrets, `system.stateVersion`) that must stay