L4D3D: survive missing textures instead of crashing at mission load

d3d_OBJECT::LoadTexture never checked D3DXCreateTextureFromFileA, cached
the NULL texture, and unconditionally AddRef()ed it - an access violation
on any missing/unreadable texture, hit by every bare working copy because
the pod skins (VIDEO\player1-8) come from the presets/replacement-material
path, not the depot. Failures now log the filename+hr and the draw op
renders untextured, matching the existing no-texture-filename path. Also
guard the unchecked gReplacementData->find() in LoadObject (same latent
UB one branch earlier).

Verified in the sandbox working copy: the game now boots to a running
RPL4 window with -windowed -egg TEST.EGG (RIO served by vRIO), logging
the eight missing pod skins instead of dying in MakeEntityRenderables.

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

docs/RP412-ROADMAP.md

@@ -105,9 +105,12 @@ TeslaConsole drives over TCP 1501 becomes in-game UI:
   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).
+- ✅ The pre-existing mission-load crash (NULL-texture `AddRef` in
+  `d3d_OBJECT::LoadTexture`) is fixed — missing textures render untextured and
+  log. The game boots standalone to a running window (BUILD.md §4). Note for
+  Workstream B: pod skins (`player1–8`) come from the presets /
+  replacement-material path the console used to drive; the in-game session UI
+  must own that.
 
 ## Suggested order