BT410: the 3-D path runs to mission load -- btl4vid's next brick is named

Run against the emulated Division card, our build reaches the mission scene
load and stops at the one method we stubbed:

  btl4vid.cpp(42): BTL4VideoRenderer::LoadMissionImplementation
                   -- btl4vid.cpp not yet reconstructed

That proves MakeVideoRenderer, the BTL4VideoRenderer ctor over the engine's
DPLRenderer, the board boot (transputer + i860 firmware, ~858K wire
transactions through the VPX HLE) and Renderer::LoadMission all work in our
build.  btl4vid is not a from-scratch climb; the engine half was always
linked and what is missing is the mission-load hook and its renderables.

Banked the reproduction rig (emulator/vidtest.conf + the host VPX env --
VPX_RESPOND alone is not enough, the iserver handshake dies without
VPX_RENDER), the authentic contract from CODE/RP/MUNGA/RENDERER.CPP:263, and
a note that the BT411 donor restructured this hook so the contract comes from
the 1995 engine and only the renderables come from the donor.

Also corrected today's earlier note: the transient 3-D frame seen during a
gauge run was NOT the dPL path.  MakeVideoRenderer returns NULL without
DPLARG and no gauge conf sets it, so no video renderer exists in those runs.

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

emulator/vidtest.conf

@@ -0,0 +1,27 @@
+[sdl]
+output=opengl
+[dosbox]
+memsize=32
+machine=svga_s3
+[cpu]
+core=normal
+cputype=pentium
+cycles=20000
+[serial]
+serial1=disabled
+serial2=disabled
+[autoexec]
+mount c "C:\VWE\TeslaRel410\emulator\image"
+c:
+set L4CONTROLS=RIO,KEYBOARD
+set L4TIMER=
+set BLASTER=A220 I5 D1 H5 P330 T6
+set VIDEOFORMAT=svga
+set BT_MECH_LOG=1
+set TEMP=c:\
+set DPLARG=/tranny~.\vrendmon.btl~/i860~.\vrnostex.mng~/device~0x150~/video~svga~/pipes~1~/qual~0x14~/system_tex~0~
+32rtm.exe -x
+BTL4REC.EXE -egg test.egg > OUTREC.TXT
+32rtm.exe -u
+echo GAME-DONE-RC=%errorlevel%
+exit

restoration/source410/RENDER-ROADMAP.NOTES.md

@@ -81,3 +81,56 @@ Message-id / protocol quick refs: vr_create=1 (host-assigned handles),
 vr_flush=3 (node structs; VIEW proves 832x512), geometry 0x17/0x19/0x1a
 (texel word [pad,B,G,R]), artics 0x1f, draw 9, sync 0x2d, fire 0x23,
 reticle 0x26. DPLARG reference value in emulator/baseline.conf:21.
+
+================================================================================
+2026-07-27 -- THE 3-D PATH RUNS TO MISSION LOAD (measured, not estimated)
+================================================================================
+Our reconstruction, run against the emulated Division card, gets ALL THE WAY to
+the mission scene load before it stops -- at the one method we stubbed.
+
+    c:/.../bt_l4/btl4vid.cpp(42): BTL4VideoRenderer::LoadMissionImplementation
+                                  -- btl4vid.cpp not yet reconstructed
+
+What that single line proves is working end to end in OUR build:
+  * BTL4Application::MakeVideoRenderer builds a BTL4VideoRenderer
+  * the BTL4VideoRenderer ctor chains the engine's DPLRenderer
+  * the board boots: transputer + i860 firmware upload, ~858K wire
+    transactions logged by the VPX device HLE
+  * Renderer::LoadMission runs (RENDERER.CPP:273) and calls the hook
+
+So btl4vid is NOT a from-scratch climb.  The engine half was always linked;
+what is missing is the game's mission-load hook and the renderables it builds.
+
+HOW TO REPRODUCE (this is the rig, and it is cheap):
+  emulator/vidtest.conf -- baseline.conf with the mount made absolute and
+  BTL4REC.EXE (our build, staged beside the shipped BTL4OPT.EXE which is NOT
+  touched) instead of the shipped exe.  Host env before launching dosbox-x:
+
+      VPX_RESPOND=1  VPX_RENDER=1  VPX_NOMAIN=1  VPXLOG=<file>  VPX_DUMPDIR=<dir>
+
+  VPX_RESPOND alone is NOT enough -- with only that, the board boot dies at
+  "Protocol error : length 65535 too big / rcv_protocol fail during iserver
+  handling", which is the iserver handshake reading a floating bus.
+  VPX_NOMAIN=1 keeps it from opening windows; add VPX_EXPLODE=1 only when you
+  want the 7-display pentapus.  The full documented pod launch is
+  render-bridge/launch_pod.ps1 (LAUNCH.md) when the GL bridge is wanted.
+
+THE CONTRACT for the next brick (authentic, CODE/RP/MUNGA/RENDERER.CPP:263):
+  Renderer::LoadMission verifies InactiveRendererStatus, sets
+  LoadingRendererStatus, stamps nextRenderTime, calls
+  GetRendererManager()->StartRenderer(this), THEN LoadMissionImplementation.
+  The base implementation Fails ("should never reach here") -- every concrete
+  renderer must override it.
+
+DONOR: BT411 game/reconstructed/btl4vid.cpp, 3188 lines / 27 methods, carrying
+the renderable family (BTReticleRenderable, BTTranslocationRenderable, the
+pending-wrecks map).  NOTE it does not contain a LoadMissionImplementation by
+that name -- the WinTesla port restructured the hook -- so take the CONTRACT
+from the 1995 engine above and the CONTENT from the donor's renderables.
+
+CORRECTION to the note earlier today: a transient 3-D cockpit frame captured
+during a gauge-rig run was NOT evidence of the dPL path emitting anything.
+MakeVideoRenderer returns NULL unless DPLARG is set (BTL4APP.CPP:152), and no
+gauge conf sets it -- so no video renderer exists in those runs at all.  That
+frame was almost certainly attract/loading art out of BTL4.RES.  The evidence
+above is the real thing, and it came from setting DPLARG deliberately.