pod displays: bind glass panels to EDID identity, not to Windows' shifting display numbers

Nick, after re-cabling + rebooting the pod: "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."

Both existing binding forms are boot-fragile: `monitor:2` is an ENUMERATION
INDEX and `monitor:\.\DISPLAY4` is a GDI name Windows reassigns.  Neither
survives a panel power-cycle.  (His gos-displays.txt shows the same trap next
door in GameOS: -tmon takes DIRECTDRAW device indices -- not Windows monitor
numbers -- and a NULL-device merge shifts every index down by one on top.)

FIX: bind to the panel's own hardware identity.  EnumDisplayDevices on a
display's MONITOR child returns a DeviceID embedding the EDID manufacturer +
product code and the connector instance; neither moves across a reboot.

  DISCOVER  BT_GLASS_IDS=1 logs every attached panel's stable-id AND a
            ready-to-paste `cfg form = monitor🆔<fragment>`.  It prints the
            VOLATILE identifiers alongside on purpose: run it either side of a
            power-cycle and index/device move while stable-id does not.
  BIND      Heat MFD=monitor:id:AUO10ED,bare

NOTHING CHANGES BY DEFAULT -- no env and no `id:` prefix means identical
behaviour; `monitor:<name|index>` and raw x,y keep working, so playtester glass
builds are untouched.

An `id:` that matches nothing WARNS and falls back to computed placement.
Silence would put a picture on the wrong glass and look exactly like the bug
this form exists to prevent.

VERIFIED on a 1-monitor dev box (the pod is offline), end to end:
  * discovery printed
      stable-id = \?\DISPLAY#AUO10ED#4&31323a6c&1&UID265988#{e6f07b5f-...}
      cfg form  = monitor:id:AUO10ED
  * `Heat MFD=monitor:id:AUO10ED,bare` resolved and CENTRED correctly
      [glasswin] 'Heat MFD' bound to monitor 0,0 1920x1080 -> window at 640,300
  * a bogus id warned instead of misplacing.
The EDID-code extractor is deliberately STRUCTURAL (3 letters + 4 hex digits,
tokenising on \ # ?) rather than positional: the first cut walked separators by
position and returned EMPTY for the `\?\DISPLAY#...` interface-name form, which
is exactly the form this machine produces.  Which form you get depends on
whether EDD_GET_DEVICE_INTERFACE_NAME succeeds, so both must parse.

STILL UNPROVEN [T3] -- the pod is offline: multi-panel disambiguation when
several MFDs share one model (EDID codes collide).  The documented answer is a
longer fragment from stable-id, whose UID/instance tail differs per connector,
but that needs the cab to confirm.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018SgmXGNMXavXiafKXf9MDC

context/pod-hardware.md

@@ -254,6 +254,40 @@ 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)
+**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 —
+`monitor:2` is an enumeration index and `monitor:\.\DISPLAY4` is a GDI name Windows reassigns.
+(Same trap next door in GameOS: its `-tmon` takes **DirectDraw device indices**, which are neither
+Windows monitor numbers nor stable, and a NULL-device merge shifts every index down by one on top
+— see Nick's `gos-displays.txt`.)
+
+**The fix: bind to the panel's own hardware identity.** `EnumDisplayDevices` on a display's MONITOR
+child returns a DeviceID embedding the **EDID manufacturer + product code** and the connector
+instance — neither moves across a reboot or a power-cycle.
+
+- **Discover:** run once on the pod with `BT_GLASS_IDS=1`. Every attached panel logs its
+  `stable-id` **and a ready-to-paste `cfg form`**:
+  ```
+  [glassid] index=0  device=\\.\DISPLAY1 PRIMARY  rect=0,0 1920x1080
+             stable-id = \\?\DISPLAY#AUO10ED#4&31323a6c&1&UID265988#{e6f07b5f-…}
+             cfg form  = monitor:id:AUO10ED
+  ```
+  The volatile identifiers print beside the stable one deliberately: run it twice across a
+  power-cycle and `index`/`device` move while `stable-id` does not — that IS the proof.
+- **Bind:** `Heat MFD=monitor:id:AUO10ED,bare` in `glass_layout.cfg`.
+- **Identical panels** (the pod's mono MFDs are likely one model, so EDID codes collide): use a
+  longer fragment from `stable-id` — the `UID…`/instance tail differs per connector, so
+  `monitor:id:UID265988` picks exactly one.
+- **An `id:` that matches nothing WARNS and falls back** to computed placement:
+  `[glasswin] monitor id 'X' matched NO attached panel`. Silence there would put a picture on the
+  wrong glass and look exactly like the bug this form exists to prevent.
+- **Nothing changes by default.** No env, no `id:` → identical behaviour; `monitor:<name|index>`
+  and raw `x,y` keep working. Playtester glass builds are untouched. [T2 verified on a 1-monitor
+  dev box — discovery, binding, centring and the mismatch warning; **T3 on the pod**, which was
+  offline: multi-panel disambiguation is unproven.]
+
 **Runbook** (`tools/podprobe.ps1`, PowerShell, no install/admin — run it ON the pod PC):
 1. Probe: GPUs, every monitor's virtual-desktop rect, EDID make/model (identifies the original
    panels), serial ports (the RIO board), session type, and a PROPOSED `glass_layout.cfg` that