Merge glass-per-display-windows: per-display cockpit windows (Cyd, BT_GLASS_PANELS)

One window per pod display (Heat/Engineering/Comm/Weapons x2/radar +
Flight Controls), each carrying its surface with its RIO button bank
arranged pod-faithfully; CPU-expanded surfaces, buttons under the
imagery.  Runtime gate BT_GLASS_PANELS (=0 = the legacy single panel).
Merged on top of today's landed fix pile (audio-crash, experience,
parallax); the L4PADRIO overlap with the gait-detent commit resolved
preserving BOTH (his window refactor + our at-rest band snap).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

# Conflicts:
#	context/glass-cockpit.md

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