Glass cockpit: per-display windows (BT_GLASS_PANELS)

Break the desktop glass cockpit's secondary displays out of the single
combined pad panel + D3D gauge strip into ONE window per pod display, each
carrying that display's surface with its RIO button bank, arranged
pod-faithfully around the main view.  New TU engine/MUNGA_L4/L4GLASSWIN.*
(BT_GLASS-only), selected by the -platform glass preset via the new runtime
gate BT_GLASS_PANELS (=0 falls back to the legacy single panel + dock).

- Surfaces are CPU-expanded from the shared gauge buffer
  (SVGA16::ExpandPlaneToBGRA, no D3D) and StretchDIBits'd in -- the D3D
  dev-composite path (dock / window / overlay) stands down while active.
- Buttons sit UNDER the imagery: big hidden click targets that reach into
  the display, with only a small protruding edge showing as a lamp light.
  Red MFD banks tile the top/bottom; radar rails run the sides + a bottom
  row; a Flight Controls window hosts the no-display banks.
- Windows: Heat / Engineering / Comm / Left Weapons / Right Weapons / radar
  + Flight Controls; edge-to-edge (no in-client margin/title; OS caption
  labels each).
- Fix blank surfaces: application/ghWnd are duplicate-defined and bind
  non-deterministically under /FORCE, so the fresh L4GLASSWIN TU read NULL.
  Reach the renderer/window via BTResolveGaugeRenderer/BTResolveMainWindow
  defined in btl4main.cpp off the real btl4App/hWnd pointers.  New gotcha:
  reconstruction-gotchas.md S6 duplicate-GLOBAL corollary.

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

context/reconstruction-gotchas.md

@@ -121,6 +121,20 @@ mislanch.cpp's extern but not projweap.cpp's → first AUTOCANNON shot AV'd). **
 bridge-signature change, `grep -rn "extern .*<name>"` and update every declaration; then grep
 the fresh link output for the symbol name** — the pre-existing LNK2019 wall camouflages new
 entries if you only eyeball it.
+**Duplicate-GLOBAL corollary (glass per-display windows, 2026-07-20):** a global DEFINED in two
+libs (the 1995 headers declare free globals without `inline`/`extern`, so `application`,
+`ghWnd`, … exist in BOTH `munga_engine` and `bt410_l4`) links under `/FORCE:MULTIPLE` with
+per-object binding that is **non-deterministic across links** — a given `.obj` can resolve
+`application` to the copy the game ASSIGNS (correct) or to the other copy (stays NULL). A
+NEWLY-ADDED engine TU is the classic victim: it read `application == NULL` forever while
+`L4VB16.cpp` in the same lib read the assigned pointer, and a relink flipped which one was
+right. Symptom: a feature that reads an engine global silently no-ops (here: the gauge
+renderer came back NULL → blank glass surfaces), no crash, no link error. **Rule: from a fresh
+TU, never touch these duplicate globals directly — resolve through a tiny accessor DEFINED in
+the TU that OWNS the real pointer** (`game/btl4main.cpp` holds `btl4App`/`hWnd` as its own
+file-scope pointers; `BTResolveGaugeRenderer()`/`BTResolveMainWindow()` there are always
+correct). Do NOT "fix" it by adding the accessor to another engine TU — that binding is just as
+random. [T2]
 
 ## 7. Dtor-epilogue rule — do not reconstruct compiler glue