Move the build to VS2022 (v143) with runtime parity against VC9

Hand-converted the four .vcproj projects to .vcxproj (Win32, v143,
Windows 11 SDK + DXSDK June 2010 for d3dx9/dxerr only). WinTesla.sln now
builds the v143 projects; the legacy solution is kept as WinTesla_vc9.sln.

Kept: /Zp1 in Munga_L4+RP_L4, Unicode, x86, /DYNAMICBASE:NO,
/FORCE:MULTIPLE (header-defined globals still duplicated across TUs).
Changed: CRT unified to /MD(d); import libs linked by the exes instead of
merged into Munga_L4.lib; WINDOWS_IGNORE_PACKING_MISMATCH and
_SILENCE_STDEXT_HASH_DEPRECATION_WARNINGS defined;
legacy_stdio_definitions.lib for the June-2010 dxerr.lib.

Source fixes, all behavior-preserving: Time gains standard (non-volatile)
copy-ctor/assignment overloads (rvalues cannot bind to volatile& in
standard C++); operator==(SOCKADDR_IN&,...) made inline; L4DINPUT's
Enum*Callback pair renamed DIEnum* (collided with L4CTRL's under LTCG);
std::ios.in -> std::ios::in in CAMMGR.cpp.

Verified: VC9 baseline rebuilt from this tree first, then the v143 build
compared against it in a sandboxed game working copy - identical logs and
behavior through RIO init (against vRIO) and mission load, including the
same pre-existing AV in d3d_OBJECT::LoadTexture (L4D3D.cpp:262) that both
toolchains hit; documented in BUILD.md 4 as the next debugging target.

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

docs/RP412-ROADMAP.md

@@ -30,6 +30,16 @@ vPLASMA renders the display's recovered command grammar
 (`VPlasma.Core/Protocol/PlasmaProtocol.cs`, grammar recovered from
 `L4PLASMA.CPP` itself). For 4.12 that logic moves *inside* the game:
 
+**Design principle — recreate the cockpit's feel on screen.** The 4.12 screen
+layout places the RIO panel controls *around* the displays in the same
+physical arrangement as the pod: MFD button clusters framing the screens,
+board columns and keypads where they sit in the cockpit, the plasma glass in
+its place above. vRIO's panel layout data (`VRio.Core`, the five MFD
+clusters / four board columns / two keypads / encoder-gauge strip) is the
+geometry reference — it is already the faithful software copy of the physical
+panel. On-screen buttons light with the same lamp states the game commands,
+so press-feedback works like the real button field.
+
 - Replace the RIO serial path in the L4 layer with a native input layer
   (keyboard / mouse / XInput, later Steam Input). Port vRIO's binding model —
   its axis-travel semantics (throttle ratchet, spring-back pedals, ±80 stick)
@@ -89,11 +99,15 @@ TeslaConsole drives over TCP 1501 becomes in-game UI:
 
 ### Toolchain
 
-- Shipping a Steam title from VC++ 2008 Express is untenable long-term
-  (no modern CRT, no Steamworks-era toolchain testing, painful CI). Early
-  task: upgrade `.vcproj` → `.vcxproj` on a branch (VS2022, `v143` toolset,
-  still Win32/DX9) and burn down the warning list. This is a prerequisite for
-  comfortable Steamworks SDK linkage.
+- ✅ **Done (2026-07-12)** — the solution builds on **VS2022 (v143)** with the
+  Windows 11 SDK; see [BUILD.md](../BUILD.md) §3 for what changed and why.
+  Runtime-verified equivalent to the VC9 baseline (including RIO init against
+  vRIO). Remaining cleanups called out there: un-`/Zp1` the Windows-header
+  boundary, port `stdext::hash_map` → `std::unordered_map`, single-TU the
+  duplicated globals so `/FORCE:MULTIPLE` can go away.
+- ⚠️ Known pre-existing crash (both toolchains): standalone mission load AVs in
+  `d3d_OBJECT::LoadTexture` (`L4D3D.cpp:262`) — first debugging target now
+  that the v143 build has full PDBs (BUILD.md §4).
 
 ## Suggested order