Glass windows remember where you drag them (BT_GLASS_LAYOUT)

The BT_GLASS_PANELS windows self-place in a pod-faithful ring and re-snap
once the main window is up.  They carry WS_CAPTION so a dev can drag them,
but the drag never survived the menu->mission->menu relaunch loop.

BT_GLASS_LAYOUT (L4GLASSWIN.cpp) adds opt-in persistence to a cwd-relative
glass_layout.cfg beside bindings.txt (gitignored):
  off/0/unset  computed ring only, no file I/O (default, pod-faithful)
  load         restore saved positions on startup (per-window fallback
               to computed); never writes
  save/adjust  restore first, then rewrite on each finished drag
               (WM_EXITSIZEMOVE) and on teardown -- the round trip

One "<title>=x,y,w,h" line per window; position restored, size ignored
(frame size is deterministic from content, so an old w,h can't distort a
later geometry change).  A restored window is flagged so ComputeLayout's
post-main-window re-snap leaves hand-placed windows alone.  Native
analogue of TeslaRel410 pod-launch's per-rig --bridge-pos/--layout args.

Verified [T2 runtime round-trip]: load restored 7 from a seeded cfg;
save wrote all 7 with a window moved to 777,333 (GetWindowRect read the
live window); relaunch in load put that window physically at 777,333
after the re-snap fired.  Release links clean (only the 40 tolerated
/FORCE externals).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/GLASS_COCKPIT.md

@@ -732,3 +732,35 @@ mode).  mkdist wraps the fragment in a doctype/charset shell and ships it beside
 - 72/72 panel addresses still dispatch on click.
 - surround / exploded / dock / pod / dev: boot + simulate, zero faults.
 - Dist carries CONTROLS.txt + a 46 KB CONTROLS.html with doctype and charset.
+
+## 2026-07-28 — Sticky per-display window placement (BT_GLASS_LAYOUT)
+
+The exploded (`BT_GLASS_PANELS`) windows self-place in the pod-faithful ring and re-snap once the
+main window appears; a dev could always drag them (they carry `WS_CAPTION`) but the drag never
+survived the menu→mission→menu relaunch loop. New **`BT_GLASS_LAYOUT`** gate (all in
+`L4GLASSWIN.cpp`, ~160 lines, no shared-file churn) persists positions to a cwd-relative
+`glass_layout.cfg` beside `bindings.txt` (gitignored):
+
+- **`off`/`0`/unset (default):** computed ring only, no file I/O — pod behaviour unchanged.
+- **`load`/`restore`:** on `Create`, after `ComputeLayout`, `LoadLayout` overrides `wantX/wantY`
+  for each window named in the file (per-window fallback to computed) and sets a `restored` flag;
+  never writes.
+- **`save`/`adjust`/`on`/`1`:** loads first, then `SaveLayout` rewrites the whole file on each
+  finished drag (`WM_EXITSIZEMOVE` in the WndProc) and once more on teardown (`Destroy`) as a
+  backstop. Writing on drag-finish means a hard kill still keeps the layout.
+
+Format: `# comment`-tolerant, one `«title»=x,y,w,h` per window; title is the stable key (no `=` in
+any title). **Position restored, size ignored** — frame size is deterministic from content
+(`AdjustWindowRect`), so an old `w,h` can't distort a later geometry change; `w,h` are written for
+reference only. The `restored` flag makes `ComputeLayout` skip that window, so the post-main-window
+re-snap leaves hand-placed windows put. Native analogue of TeslaRel410 `emulator/pod-launch`'s
+per-rig `--bridge-pos`/`--layout` args.
+
+### Verified [T2, runtime round-trip]
+- Build: Release links clean, only the 40 tolerated `/FORCE` externals, no compile errors.
+- `load`: seeded a distinctive cfg → log `restored 7 window position(s)`, cockpit up, mission ran.
+- `save`: moved *Flight Controls* to (777,333) + drove `WM_EXITSIZEMOVE` → cfg written with all 7
+  rects, the moved one at `777,333` (proves `GetWindowRect` read the live window), others at ring.
+- round-trip: relaunched `load` against the game-written cfg → after 12 s (past the re-snap) the
+  *Flight Controls* window was physically at (777,333), all 7 at their saved coords — the re-snap
+  guard held.