pod: EDID monitor:id binding DEPLOYED + verified on ALPHA-MR; runbook updates (Default_Monitor radar identity, cmd 1>> trap, tester-procedure deploy verified)

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

context/pod-hardware.md

@@ -254,7 +254,22 @@ desktops. Two pieces were added for the cab:
   once, and over CRD you cannot see the panels at all: the log IS the confirmation that a picture
   landed on the right glass.
 
-### Boot-STABLE panel binding — `monitor:id:` (2026-08-08, staged, pod-untested)
+### Boot-STABLE panel binding — `monitor:id:` (DEPLOYED + POD-VERIFIED 2026-08-10)
+**Live on ALPHA-MR since 2026-08-10** — mapping eye-verified over livestream, then the master
+`C:\bt411\glass_layout.cfg` flipped to the id form (old cfg saved as
+`glass_layout.cfg.displaynbak`) and the relaunch bound all three windows to the SAME rects with
+zero mismatch shouts [T2]. The shipped binding:
+```
+Secondary / Radar=monitor:id:Default_Monitor,bare   # colour radar LCD, USB adapter
+VGA Port A=monitor:id:UID224795,bare                # RAR0005: Heat + Comm + Mfd2 CRTs
+VGA Port B=monitor:id:UID200195,bare                # RAR0005: Mfd1 + Mfd3 CRTs
+```
+⚠ **The radar LCD's USB display adapter presents NO EDID** — its only stable identity is the
+`Default_Monitor` placeholder (`…#Default_Monitor#…&UID256#`). Unique today; a second EDID-less
+panel would collide, and the per-boot `[glassid]` dump (BT_GLASS_IDS=1, now PERMANENT in
+`podprofile.ini`) plus the mismatch shout are the diagnosis tools. The Dell (`DEL4025`) is the
+PRIMARY main-view panel (BT_FIT owns it; not in the layout cfg) — the 08-08 note calling it a
+"1908FP" service monitor mis-guessed its role.
 **Windows renumbers displays.** Nick, after re-cabling + a reboot: *"the order changed … sometimes
 they change when one gets turned off and back on, at least how windows SEEs them, even if the
 visual desktop tool looks the same."* So the two original binding forms are both boot-fragile —
@@ -480,8 +495,20 @@ instantly and did nothing" actually means "it is still hung". Recover with
 without a GUI):** `DISPLAY\RAR0005\…UID224795`, `DISPLAY\DEL4025\…UID249395` (DELL 1908FP),
 `DISPLAY\RAR0005\…UID200195`. **The two RAR panels share one EDID code and have blank serials**, so
 `monitor:id:RAR0005` is ambiguous — they must be bound by the per-connector form
-(`monitor:id:UID224795` / `monitor:id:UID200195`). The Dell's code is unique. The cab's shipped
-`glass_layout.cfg` still uses the fragile `monitor:DISPLAY4` device-name form.
+(`monitor:id:UID224795` / `monitor:id:UID200195`). **RESOLVED 2026-08-10:** the full map is
+UID224795 = VGA Port A (Heat+Comm+Mfd2), UID200195 = VGA Port B (Mfd1+Mfd3), `Default_Monitor`
+(EDID-less USB adapter, UID256) = the colour radar LCD, DEL4025 = the PRIMARY main-view panel
+(not a service monitor). The master cfg now ships the id form (see the binding section above);
+`glass_layout.cfg.displaynbak` preserves the old DISPLAYn cfg.
+
+**7. ⚠ cmd redirect trap when scripting over SSH:** `echo VAR=1>> file` appends `VAR=` — cmd
+parses the digit-adjacent `1>>` as a stream-handle redirect and eats the value (and MSVC putenv
+treats an EMPTY value as UNSET, so the flag silently never arms). Space it (`echo VAR=1 >>file`,
+trailing-space payload) or use PowerShell `Add-Content`. Bit us arming BT_GLASS_IDS 2026-08-10.
+
+**8. Tester-procedure deploy VERIFIED end-to-end (2026-08-10, build 876):** scp zip →
+`Expand-Archive` → podkit → `schtasks /run` came up clean on the first try — rig config survived,
+newest-install auto-resolve worked, no hand-edits. The cab genuinely upgrades like a tester box.
 
 ## The 1995 player manual — alignment audit (2026-07-18) [T1, primary source]
 `reference/manual/Tesla40_BT_manual.pdf` (34pp, from Nick). CONFIRMS the reconstruction on