merge fix-ups: the four review findings + a build portability gate the merge exposed

Applied on top of the glass-cockpit-refit merge, all from the pre-merge review:

1. README CONTROLS TABLE REWRITTEN for the new default board.  It still taught
   "W/S throttle, A/D turn" while the defaults moved flight to the numpad and
   handed the letter rows to the MFD banks -- a fresh install would read
   controls that do not work.  The new table teaches the numpad flight block,
   the panel-on-your-keys groups, F7 for control mode (was M), backtick for the
   camera (was V), the coolant valves on 1-3/QWE with the detent warning kept,
   and PgUp/PgDn volume.  UPGRADERS ARE TOLD EXPLICITLY that their preserved
   bindings.txt keeps their old keys, and that deleting it opts into the board.

2. BACKTICK VIEW-TOGGLE GUARDED.  The bindings-row-wins rule (KeyHasBinding)
   covered V and J/K/L but not backtick itself, which polled unconditionally --
   and BACKTICK is a nameable, unbound key, so binding it to a button
   double-dispatched (button + camera).  Both halves of the view poll are now
   guarded.

3. ENVIRON.INI REFUSES ONE-SHOTS.  The loader applied ANY key=value line, and
   BT_JOYCONFIG in the file would defeat the #66 one-shot in a sneaky way: the
   wizard DELETES the process var after running, so in every relaunched child
   there is no real env var left to win over the file -- capture wizard at
   every mission start.  BT_JOYCONFIG is now skipped with the reason in the
   template header, which also warns that test/debug hooks (BT_MP_FORCE_DMG
   and friends) do not belong in a file that silently persists forever.

4. VOLUME DOCUMENTED EVERYWHERE IT WAS MISSING.  CONTROLS.md gains the
   PgUp/PgDn row (the old "- / = (see below)" cell pointed at a note that never
   mentioned volume) and the note that the keys moved so they no longer share a
   key with anything in any layout; the bindings template header reserves
   PgUp/PgDn informally.

5. L4KEYLIGHT BUILD GATE (found by building the merge on this machine).  The
   C++/WinRT Dynamic Lighting TU does not compile against SDK 10.0.19041 --
   its bundled cppwinrt fails inside winrt/base itself (C2039 'wait_for').
   CMake now detects an SDK older than 10.0.22000 and builds a dormant stub
   with the same five-function scalar interface (logs once at Start, identical
   behaviour otherwise) -- extending the feature's own runtime philosophy
   ("no Dynamic Lighting -> log once, stay dormant") to build time.  Dynamic
   Lighting is a Windows 11 22H2 feature, so nothing real is lost on an older
   build machine, and machines with a newer SDK build the real mirror
   unchanged.

VERIFIED on the merged tree (4.11.572):
  * build clean -- 0 compile errors; the 40 /FORCE-tolerated unresolved
    externals are byte-identical to every pre-merge build (20
    CreateStreamedSubsystem + 20 DefaultData; the earlier claim that all 40
    were CSS was shorthand -- corrected here for the record).
  * solo boot: environ.ini template written + loaded, mode resolver announces
    the surround, historical bands L276/R276/T223/B336 confirmed, keylight
    stub logs its dormant line, BT_SHOT capture shows the under-glass button
    treatment and the corrected hat labels, 0 faults.
  * PgUp/PgDn volume PROVEN LIVE via injected keys: 5%->10%->15%->10%, saved
    to volume.cfg.  (Side catch: content\volume.cfg had been sitting at 0.00
    from an old test -- anyone using this tree had a silent game; reset.)
  * full relay cycle on the merged exe: 2 pods staged, launch pair, mission,
    StopMission, round RESET -- all clean.
  * all three console suites still pass; checkctx CLEAN.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

engine/MUNGA_L4/L4KEYLIGHT.cpp

@@ -20,6 +20,40 @@
 // on-screen cockpit buttons blink in step).
 //===========================================================================//
 
+//
+// BUILD-TIME STUB GATE (merge 2026-07-26).  The C++/WinRT body below needs a
+// Windows SDK whose cppwinrt headers are new enough for Dynamic Lighting --
+// SDK 10.0.19041's fail inside winrt/base itself (C2039 'wait_for').  On a
+// build machine with only an older SDK, CMake defines BT_KEYLIGHT_STUB and
+// this TU compiles the dormant stub instead: same five-function scalar
+// interface, logs once at Start(), the game runs identically otherwise.
+// This extends the feature's own runtime philosophy (no Dynamic Lighting ->
+// log once, stay dormant) to build time, and keeps the link closed on every
+// machine without demanding an SDK upgrade.
+//
+#if defined(BT_KEYLIGHT_STUB)
+
+#include "l4keylight.h"
+
+static void (*s_stubLogger)(const char *line) = 0;
+
+void KeyLight_SetLogger(void (*logger)(const char *line))
+{
+	s_stubLogger = logger;
+}
+void KeyLight_SetMap(const int *, const int *, const unsigned char *, int) {}
+void KeyLight_UpdateLamps(const unsigned char *, int) {}
+void KeyLight_Start()
+{
+	if (s_stubLogger)
+		s_stubLogger("[keylight] built without Dynamic Lighting support "
+		             "(Windows SDK too old at COMPILE time) -- RGB mirror "
+		             "dormant on this build");
+}
+void KeyLight_Stop() {}
+
+#else  // the real C++/WinRT mirror
+
 #include <windows.h>
 
 #include <atomic>
@@ -404,3 +438,5 @@ void
 		gWorker.join();
 	}
 }
+
+#endif  // BT_KEYLIGHT_STUB

engine/MUNGA_L4/L4PADBINDINGS.cpp

@@ -277,6 +277,9 @@ static const char *defaultProfileText =
 "key LALT button 0x3F\n"
 "key RALT button 0x3F\n"
 "\n"
+"# PgUp/PgDn are the VOLUME keys (built in; they produce no typed character\n"
+"# so they can never collide with a hotkey) -- leave them unbound.\n"
+"\n"
 "# --- the four mappable fire buttons ------------------------------------\n"
 "# The mouse's side buttons are free if you want them on the trigger:\n"
 "#   key MOUSE4 button 0x40\n"

engine/MUNGA_L4/L4PADRIO.cpp

@@ -649,8 +649,15 @@ void
 	// exists to prevent.  Bind the key, and the built-in stands down.
 	{
 		static int s_backtickWas = 0;
+		// BOTH halves are KeyHasBinding-guarded (merge review 2026-07-26): the
+		// V half already was, but backtick polled unconditionally -- and
+		// BACKTICK is a nameable, unbound key, so a player who bound it to a
+		// button got a double-dispatch (button + camera toggle), the exact
+		// hazard the bindings-row-wins rule exists to prevent, in the one poll
+		// it had not been applied to.
 		int backtick_held = focused &&
-			(((GetAsyncKeyState(VK_OEM_3) & 0x8000) != 0) ||
+			((!KeyHasBinding(VK_OEM_3)
+			  && (GetAsyncKeyState(VK_OEM_3) & 0x8000) != 0) ||
 			 (!KeyHasBinding('V') && (GetAsyncKeyState('V') & 0x8000) != 0));
 		if (backtick_held && !s_backtickWas)
 		{