UNIFY: one exe -- retire the pod/glass/steam compile split

The three build dirs (build\ pod, build-glass\, build-steam\) were compile-
time splits of the same game; the tax was real: a stale steam exe shipped 2
days behind, the felt keymap flipped with the boot flavor, and cockpit
clicks were silently dead in the pod build (the trigger-config incident).

Now everything compiles into the single build\ exe:
- CMakeLists: BT_GLASS/BT_STEAM options removed; the glass TUs (PadRIO,
  bindings, panel, glass windows, plasma) + FE/console + Steam transport
  compile unconditionally; both macros always defined (seam markers).
- Steam: steam_api.lib linked with /DELAYLOAD:steam_api.dll + delayimp --
  the DLL maps only when SteamAPI is first called, and every call site
  gates on BT_STEAM_NET=1 (BTSteamNet_* short-circuit on steamActive), so
  machines without the DLL run everything but Steam sessions.
- CABINET GUARD (btl4main): the miniconsole menu previously claimed any
  zero-arg launch -- unified, that would hijack the pod cabinet's boot
  shape.  The menu now requires BT_PLATFORM=glass (or BT_FE_MENU=1);
  platform parse moved above the fe_menu_mode computation.  A bare boot
  behaves exactly like the old pod build (DEV profile, wait for egg).
- Bats (play_solo/join/join_lan/play_steam) + the btoperator.py template:
  single build\ path + BT_PLATFORM=glass.  mkdist: one exe (+DLL scan
  picks up OpenAL32 + steam_api).  build-glass\/build-steam\/build-glass2\
  (a stale Jul-20 cache) deleted.

Verified matrix on the unified exe:
  bare zero-arg boot == old pod exe (same DEV profile + egg-load path;
    the segfault on a missing egg is pre-existing, baselined vs the zip exe)
  glass + BT_BTNTEST scripted click -> [cfgmap] ENTER/EXIT (trigger config)
  runs with steam_api.dll ABSENT (delay-load proven)
  glass zero-arg -> miniconsole menu
  2-node loopback MP: 145 ticks each, cross-connected
  BT_STEAM_NET=1 without Steam client -> "staying on Winsock", game runs

KB: context/glass-cockpit.md compile-gates section rewritten for the
unified model.

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

game/btl4main.cpp

@@ -289,15 +289,6 @@ int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine
 	// the child inherited L4CONTROLS=KEYBOARD, and the glass preset could
 	// never select PAD -- no PadRIO, no panel, plasma only).
 	//
-	int fe_menu_mode = 0;
-#ifdef BT_GLASS
-	{
-		int fe_has_egg = lpCmdLine && strstr(lpCmdLine, "-egg") != NULL;
-		int fe_has_net = lpCmdLine && strstr(lpCmdLine, "-net") != NULL;
-		fe_menu_mode = !fe_has_egg && !fe_has_net && getenv("BT_FE_EGG") == NULL;
-	}
-#endif
-
 	int gBTPlatformPod = 0;
 	int gBTPlatformGlass = 0;
 	{
@@ -315,15 +306,21 @@ int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine
 			if (pv[0] && _stricmp(pv, "glass") == 0)
 				gBTPlatformGlass = 1;
 		}
-#ifndef BT_GLASS
-		if (gBTPlatformGlass)
-		{
-			std::cout << "[boot] platform 'glass' ignored: not in this build "
-				"(configure with -DBT_GLASS=ON); falling back to DEV"
-				<< std::endl << std::flush;
-			gBTPlatformGlass = 0;
-		}
-#endif
+	}
+
+	// UNIFIED-BUILD GUARD (2026-07-21): the miniconsole menu is a GLASS-
+	// platform feature.  It must NOT claim a bare zero-arg boot -- that is
+	// the POD CABINET's launch shape (DEV profile, wait for the console
+	// egg).  The menu runs only when the glass platform is selected
+	// (BT_PLATFORM=glass / -platform glass, e.g. play_steam.bat) or forced
+	// with BT_FE_MENU=1.  (Platform parse moved ABOVE this block so the
+	// flag is available; it reads only env/cmdline, no profile putenvs.)
+	int fe_menu_mode = 0;
+	{
+		int fe_has_egg = lpCmdLine && strstr(lpCmdLine, "-egg") != NULL;
+		int fe_has_net = lpCmdLine && strstr(lpCmdLine, "-net") != NULL;
+		fe_menu_mode = !fe_has_egg && !fe_has_net && getenv("BT_FE_EGG") == NULL
+			&& (gBTPlatformGlass || getenv("BT_FE_MENU") != NULL);
 	}
 
 	if (fe_menu_mode)