pod: make the frozen rig survive a NEW BUILD, not just a reboot

Both frozen files live inside the versioned install and neither ships in the
zip -- environ.ini is generated on first run, glass_layout.cfg is ours.  So
Nick extracting the next build would get a cab that comes up wrong with no
error anywhere, which is exactly the failure the freeze was supposed to end.

Masters now live at the stable C:\bt411\ (podprofile.ini, glass_layout.cfg,
podkit.ps1).  setup_pod.bat pushes them into the newest BT411_* folder -- run
once per extract.  runpod.bat resolves the newest install and applies the kit
itself, so the remote launch path needs no per-build edit.  Re-tuning means
editing the MASTER: the apply overwrites the install's copy on purpose, so a
moved panel has one place to look.

Also records, for playtesting on the cab: all five tester launchers set no pod
key at all, so each inherits the rig from environ.ini without knowing the pod
exists -- verified by running play_solo.bat on the cart (7 settings applied,
not 9, because the bat sets BT_PLATFORM and BT_START_INSIDE itself and the
real environment wins).  That is the case against a separate pod-only ini: a
second file would need every launcher to opt in.

Verified: kit re-applies idempotently, and the rewritten runpod.bat brings the
cab up correct -- 9 settings, GLASS, -fit borderless, all three surfaces on
their intended displays.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Rw7No5wLTpkaUgA3ANbtZZ

context/pod-hardware.md

@@ -317,6 +317,28 @@ Verified on build 4.11.813 with the launcher carrying none of it: `[boot] enviro
 setting(s) applied`, `[cockpit] -fit: borderless 800x600`, `[glasswin] radar rotation 0 (none)`,
 and all three surfaces on their intended `\\.\DISPLAYn`.
 
+**Surviving a NEW BUILD, not just a reboot.** Both frozen files live INSIDE the versioned install
+(`content\environ.ini`, `content\glass_layout.cfg`) and NEITHER ships in the zip — environ.ini is
+generated on first run. So extracting a new build gives a cab that comes up wrong with no error
+anywhere. The masters therefore live at the stable `C:\bt411\` (`podprofile.ini`,
+`glass_layout.cfg`, `podkit.ps1`), and **`setup_pod.bat` pushes them into the newest `BT411_*`
+folder** — run it once after each extract. `runpod.bat` resolves the newest install and applies
+the kit itself before launching, so the remote path needs no hand-editing per build. Re-tuning the
+cab means editing the MASTER at `C:\bt411\`, not the install's copy: the apply overwrites it, on
+purpose, so there is one place to look when a panel moves. Repo copies: `scratchpad/pod/`.
+
+**The tester launchers work on the cab unchanged (verified 2026-08-06) [T2].** `play_solo.bat`,
+`join.bat`, `join_lan.bat`, `play_steam.bat` and `joyconfig.bat` set `BT_PLATFORM=glass`,
+`BT_START_INSIDE=1`, `BT_DEV_GAUGES=1` plus their own mode flag — and **not one pod key** between
+them. So each inherits the whole rig from environ.ini without knowing the pod exists. This is the
+argument against a separate pod-only settings file: a second file would need every launcher to opt
+in, which is the shape of the "competing keymaps" bug that made glass the default profile.
+Observed: `play_solo.bat` on the cart logs `environ.ini: 7 setting(s) applied` — 7 not 9, because
+the bat sets `BT_PLATFORM` and `BT_START_INSIDE` itself and the real environment wins.
+Steam MP needs the **client installed and logged in** (AppID 480/Spacewar, so any account, no
+purchase); installed on the cart 2026-08-06. ⚠ **#68: a failed JOIN/HOST exits the process
+SILENTLY** — "Steam not running" and a real crash look identical to a player.
+
 **Working on the cart, remotely.** SSH over Tailscale lands in **session 0**, which has a dummy
 "WinDisc" display and CANNOT see or enumerate session 1's windows — GUI work must go through
 `schtasks /run /tn BT411Run` (task registered `/IT`), and window enumeration over SSH silently