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>

.gitignore

@@ -30,6 +30,8 @@ content/environ.ini
 content/frontend.egg
 content/steam_appid.txt
 content/fe_last.ini
+content/glass_layout.cfg
+glass_layout.cfg
 # local root copies of the player bats (players/ is the source of truth)
 /play_solo.bat
 /joyconfig.bat