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>

CLAUDE.md

@@ -31,32 +31,73 @@ machines when deployed.
   the auto-installer (see `docs/auto-installer.md`). Never commit its
   contents; if `git status` ever shows it as trackable, something is wrong.
 
-### `pve.sweet.home` (the Proxmox node)
+### Two Proxmox nodes: `pve1.sweet.home` (production) and `pve-test.sweet.home` (sandbox)
 
-`pve.sweet.home` (`PROXMOX_HOST` in `scripts/env.sh`) is a real, live Proxmox
-node hosting production VMs/containers — not a sandbox.
+There are two SSH-reachable Proxmox nodes on the LAN, both defined in
+`scripts/env.sh` (`PVE1_HOST` / `PVE_TEST_HOST`), individually targetable
+via `scripts/proxmox/create-proxmox-resource.sh --node <host>` or by
+overriding `PROXMOX_HOST`. `PROXMOX_HOST` itself still defaults to
+`PVE1_HOST` (production) — that default, and every other script behavior,
+is unchanged from before `pve-test` existed; the only thing new is that
+`pve-test` can now be reached at all. They are **not interchangeable** —
+one is real production infrastructure, the other exists specifically so
+there's somewhere safe to test. The restriction below is a policy for
+Claude specifically, not a change to the tooling's own default or
+anything the operator needs to opt into.
 
-- **Read-only for existing state.** You may SSH in (or use `pvesm`, `qm
-  list`, `pct list`, `qm config`, `pct config`, the Proxmox API, etc.) to
-  inspect the node's config, storage, and any existing VM/container —
-  including ones this repo didn't create. Never modify, stop, restart,
-  delete, or reconfigure anything that already exists there (`qm set`,
-  `pct set`, `qm destroy`, `pct destroy`, `qm stop`, `pct stop`, snapshot
-  operations, storage changes, etc.) without the operator's explicit
-  go-ahead.
-- **Test VMs/containers are allowed, but must be torn down.** You may create
-  a scratch VM or container on the node (e.g. via
-  `scripts/proxmox/create-proxmox-resource.sh` or raw `qm`/`pct create`) to
-  validate something. Anything you create this way must be destroyed again
-  in the same session, before ending the task — never leave a test
-  resource running on the node. Use a VMID/name that's obviously scratch
-  (and doesn't collide with a real flake target) so it's unambiguous what's
-  safe to remove.
-- **No changes to production, ever, from an agent session** — this covers
-  both the node itself (Proxmox host config, storage pools, networking) and
-  any pre-existing guest. Anything beyond inspecting and tearing down your
-  own scratch resources is the operator's call to make manually, same as
-  the deploy commands above.
+#### `pve1.sweet.home` (production — off-limits to Claude)
+
+A real, live Proxmox node hosting production VMs/containers — not a
+sandbox, and not Claude's to touch by default.
+
+- **Off-limits at all times unless the operator has given explicit,
+  same-session instructions to act on this specific host.** That
+  authorization is scoped to the task it was given for — don't carry it
+  forward to unrelated later work in the same conversation, and never
+  assume it from a previous session.
+- **Read-only for existing state is always fine, authorization or not.**
+  You may SSH in (or use `pvesm`, `qm list`, `pct list`, `qm config`, `pct
+  config`, the Proxmox API, etc.) to inspect the node's config, storage,
+  and any existing VM/container — including ones this repo didn't create.
+- **Never** modify, stop, restart, delete, reconfigure, or create anything
+  on this node (`qm set`, `pct set`, `qm destroy`, `pct destroy`, `qm
+  stop`, `pct stop`, `qm create`, `pct create`, snapshot operations,
+  storage changes, etc.) — including scratch/test resources — without
+  that explicit go-ahead. Use `pve-test.sweet.home` for anything
+  exploratory instead; it exists precisely so `pve1` never has to be the
+  answer to "where do I test this."
+- **This is a Claude-specific policy, not something the scripts enforce.**
+  `scripts/env.sh`/`create-proxmox-resource.sh` default to `pve1` exactly
+  as they did before `pve-test` existed, with no extra flag or prompt
+  required — that's deliberate, so the operator's own existing workflows
+  don't change. Claude, however, must never rely on that default: every
+  Proxmox action Claude takes on its own initiative — not explicitly
+  pointed at `pve1` by the operator this session — targets `pve-test`
+  instead (e.g. `--node "$PVE_TEST_HOST"`, or `PROXMOX_HOST=$PVE_TEST_HOST`).
+  Claude's own default is `pve-test`, full stop, regardless of what the
+  tooling's own unqualified default happens to be.
+
+#### `pve-test.sweet.home` (sandbox — Claude's default target)
+
+A separate Proxmox node set aside for testing. The *tooling's* default is
+still production (`PROXMOX_HOST` → `PVE1_HOST`, see above) — but
+**Claude's own default is this node**: absent an explicit, same-session
+instruction to use `pve1`, every Proxmox action Claude initiates targets
+`pve-test`. Once targeted, it's safe to create, interrogate, and destroy
+resources on without asking first.
+
+- **Test VMs/containers are allowed, but must be torn down.** Create a
+  scratch VM or container here (e.g. via
+  `scripts/proxmox/create-proxmox-resource.sh` or raw `qm`/`pct create`)
+  to validate something. Anything created this way must be destroyed
+  again in the same session, before ending the task — never leave a test
+  resource running. Use a VMID/name that's obviously scratch (and doesn't
+  collide with a real flake target) so it's unambiguous what's safe to
+  remove.
+- **Node-level config is still not yours to change.** Creating/destroying
+  your own scratch guests is fine; Proxmox host config, storage pools, and
+  networking on `pve-test` itself are still the operator's call to make
+  manually, same as on `pve1`.
 
 ## Commands