wiki/memory: retire GuruRMM 'VM' framing + correct Windows build chain

Two sweeps:
1. .30 is a PHYSICAL box (Lenovo ThinkCentre M83, Ubuntu 26.04), not a Jupiter
   VM — the VM was decommissioned 2026-06-12. Fixed inventory tables and the
   gururmm-build system page (overview, index, jupiter, gururmm-build,
   POWER_FAILURE_RUNBOOK).
2. Windows build chain: Beast (GURU-BEAST-ROG, tailnet 100.101.122.4, i9-14900K)
   is PRIMARY; Pluto (172.16.3.36) is FALLBACK. Verified against build-windows.sh
   (`attempt_build beast || attempt_build pluto`). Fixed overview, index,
   projects/gururmm (build-host table + flow + host detail), systems/pluto, and
   the reference_pluto_build_server memory.

Submodule advanced: build-pipeline doc comments corrected to match.

wiki/systems/pluto.md

@@ -19,7 +19,7 @@ backlinks:
 ## Identity
 - **Hostname:** Pluto / Claude-Builder
 - **IP:** 172.16.3.36
-- **Role:** Windows MSVC build server — produces GuruRMM Windows agent binaries + WiX MSI, and (2026-05-29) the **GuruConnect** Windows agent. Hosts a Gitea Actions runner for guru-connect's native MSVC builds.
+- **Role:** Windows MSVC build server. For **GuruRMM** Windows agent + WiX MSI builds it is now the **FALLBACK** — Beast (GURU-BEAST-ROG, tailnet 100.101.122.4) is PRIMARY, and `build-windows.sh` only falls through to Pluto if Beast is unreachable/down or its build fails. Still produces the (2026-05-29) **GuruConnect** Windows agent and hosts a Gitea Actions runner for guru-connect's native MSVC builds.
 - **RMM agent identity:** enrolled in GuruRMM as hostname **PLUTO** (client "AZ Computer Guru"). Drive it via `/rmm` (resolve PLUTO → agent id at runtime) when a workstation SSH key isn't authorized. There is **no dedicated `pluto` vault entry** — don't search for one.
 - **Location:** VM on Jupiter (172.16.3.20), Unraid/virsh **VM name "Claude-Builder"** (= PLUTO = 172.16.3.36, same machine)
 - **OS:** Windows Server 2019 Standard