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>

context/glass-cockpit.md

@@ -114,6 +114,31 @@ each, so they cover the foot band too, and the hit test takes the first match
 what keeps 0x16/0x17/0x1F/0x1E reachable. That class of bug is why the verification below tests
 first-hit reachability, not mere presence.
 
+## Sticky window placement — BT_GLASS_LAYOUT (2026-07-28) [T2 round-trip-verified]
+
+The `BT_GLASS_PANELS` windows self-place in a pod-faithful ring around the main window
+(`ComputeLayout`, then a one-shot re-snap once the real main window is up). They carry
+`WS_CAPTION` in every mode, so a dev can always drag them — but by default a drag does **not**
+survive relaunch (and the menu→mission→menu loop relaunches the process each hop). **`BT_GLASS_LAYOUT`**
+(`L4GLASSWIN.cpp`) adds opt-in persistence to a cwd-relative `glass_layout.cfg` (beside
+`bindings.txt`; gitignored):
+
+| `BT_GLASS_LAYOUT` | Behaviour |
+|---|---|
+| unset / `off` / `0` | computed ring only, no file I/O (**default** — pod-faithful, unchanged) |
+| `load` / `restore` | restore saved positions on startup (per-window fallback to computed for any not in the file); never writes |
+| `save` / `adjust` / `on` / `1` | restore first, **then** re-write the whole file on each finished drag (`WM_EXITSIZEMOVE`) and on teardown — the round-trip "adjust" mode |
+
+Mechanics: `glass_layout.cfg` is `# comment`-tolerant, one `«window title»=x,y,w,h` line per
+window (title is the stable key — titles carry no `=`). **Position is restored; size is not** —
+each window's frame size is deterministic from its content (`AdjustWindowRect`), so honouring an
+old saved `w,h` could distort a later geometry change; the `w,h` are written for reference only.
+A restored window sets a `restored` flag that makes `ComputeLayout` skip it, so the post-main-window
+re-snap leaves hand-placed windows alone (round-trip verified: a window saved at 777,333 came back
+at exactly 777,333 after the re-snap fired). Save fires on `WM_EXITSIZEMOVE` (survives a hard kill,
+since it writes as soon as a drag finishes) with a teardown write as backstop. This is the native
+analogue of TeslaRel410 `emulator/pod-launch`'s per-rig `--bridge-pos`/`--layout` placement args.
+
 **Verified 2026-07-26 [T2]:** `BT_RIOBANK_LOG=1` dumps every bank's rects;
 `scratchpad/checkbank.py` reports the per-bank census and proves no address is SHADOWED (has a
 point no earlier button covers); `scratchpad/clickbank.py` then posts a real click at every