vPOD: real C:\Games installs, optional real app launching, power-group swap

- InstallProduct now extracts into the real C:\Games (the launcher's
  GAMES_DIR) so deployed products land where their catalog launch entries
  point; uninstall removes the real product folder. Tests pass an isolated
  games root through the VirtualLauncher ctor.
- New "Actually launch apps (real processes)" toggle (off by default =
  simulated PIDs): LaunchApp starts the entry's exe exactly like the Agent
  (same start info, same registered-but-not-installed error), Kill*/
  Uninstall/Wipe terminate the real processes (kill before folder delete),
  and self-exited apps are pruned from GetLaunchedApps/FullUpdate. Real
  processes die with the machine: power off, reboot, or closing vPOD. The
  Agent's autoRestart watchdog is deliberately not emulated.
- Pod Power and Mimicking Game groups swapped (game left, power right).
- Provisioning round-trip test now skips as inconclusive when a running
  TeslaConsole holds UDP 53291 instead of failing the suite; two new tests
  cover real launch/kill (ping.exe) and the missing-exe error path.

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

vPOD/README.md

@@ -91,25 +91,36 @@ so provisioning is one-time. **Reprovision** resets to a fresh pod — drops the
 key, clears the installed-apps store (`LaunchApps.json`) and returns to beacon
 mode — pair it with deleting the pod in Manage Site (the console's
 **Reconfigure…** does both ends automatically: its `ClearStore` makes vPOD do
-the same wipe and beacon again). Extracted packages under `Games\` are left on
-disk either way.
+the same wipe and beacon again). Extracted packages under `C:\Games` are left
+on disk either way.
 
 ### Product deployments
 
 Right-click the pod row → **Install Product ▸** works exactly as against a real
 pod: the console streams the package zip out-of-band on a second 53290
-connection while polling progress on the first; vPOD extracts it into its
-virtual games root and reports the launcher's usual `0–50%` receive / `50–95%`
-extract / `99% Complete` progression. Then:
+connection while polling progress on the first; vPOD extracts it into the real
+`C:\Games` — the launcher's games root, so products land where their catalog
+launch entries point — and reports the launcher's usual `0–50%` receive /
+`50–95%` extract / `99% Complete` progression. Then:
 
 - Installed apps land in the column's list (and in `GetInstalledApps`, so the
   Uninstall menu populates). Registrations persist in
   `%LocalAppData%\vPOD\LaunchApps.json`.
-- Packages extract under `%LocalAppData%\vPOD\Games\` (the virtual `C:\Games`).
-  A packaged `postinstall.bat` is logged and removed but **never executed**.
-- **Launch/Kill** from the squad panel are simulated (fake PIDs, no real
-  process); Volume round-trips; **Restart/Shutdown** power-cycle the virtual
-  pod (dark for a few seconds on restart).
+- Packages extract into `C:\Games` (created on first install if missing; if an
+  admin-owned `C:\Games` isn't writable by your account, the install reports
+  Failed — fix the folder's ACL or run vPOD elevated). Uninstalling a product
+  removes its `C:\Games\<product>` folder, like the real launcher. A packaged
+  `postinstall.bat` is logged and removed but **never executed**.
+- **Launch/Kill** from the squad panel simulate PIDs by default. The
+  **"Actually launch apps (real processes)"** checkbox switches to the real
+  Agent's behavior: LaunchApp starts the entry's exe from `C:\Games` (missing
+  exe → the same "registered but not yet installed" error a real pod gives),
+  Kill\* terminate the processes, and apps that exit or crash on their own
+  disappear from the console's running list. Real processes also die when the
+  pod is powered off / rebooted / the vPOD window closes. Caveat: launching a
+  *deployed vPOD* or a real game client this way will fight the running vPOD
+  for ports 1501/53290. Volume round-trips; **Restart/Shutdown** power-cycle
+  the virtual pod (dark for a few seconds on restart).
 
 ### Ports
 
@@ -127,8 +138,9 @@ Same-machine testing needs no firewall changes (loopback). Running vPOD on a
 Not emulated: the console's remote Windows-service control (`ServiceController`
 over SCM/SMB, used by some SitePanel service start/stop paths — dormant against
 real pods too, since it queries service name `TeslaLauncherService` while the
-launcher registers as `Tesla Application Launcher`), and really launching
-deployed exes (a second game client would fight vPOD for its own ports).
+launcher registers as `Tesla Application Launcher`), and the Agent's
+`autoRestart` watchdog (a real-launched app that dies is pruned from the
+running list, not relaunched).
 
 An end-to-end loopback test of this server against the console's real
 `PodManagerConnection` client lives in the differential suite: