BT410 5.3.60: first rendered frame from a running reconstructed mission

emulator/render-bridge/first_mission_frame.png -- arena city, textured
buildings, horizon, 28fps, captured from the GL bridge while our build ran a
live mission with the mech walking.  The skeleton went in with it:
[skl] video\mad.skl -> 26 nodes, 19 objects.

Corrects yesterday's RIO framing.  I called serial1 an unplugged cable.  Wrong
twice: VRio.App is running on this rig (the dev-rig default since 7/17), and
the emulator log recorded real byte counts on that port -- RX overruns of 471,
503, 528 -- which an unconnected pipe cannot produce.  The port was LIVE and
streaming during every crashing run.

So the defect is not that we mishandle a disconnected port, it is that we
mishandle a live RIO stream, which is worse: every production pod has a real
RIO.  The shipped binary on the same rig logs 'lost RIO analog request', keeps
sending characters, and runs the mission; ours logs 'RIO never came back from
test mode!' and dies partway through the load.  The overrun counts say the
guest is not draining the port fast enough.  L4RIO.CPP's handshake is authentic
archive code, but MechRIOMapper (BT/MECHMPPR.CPP) is ours -- that is the thread.

pod_render_norio.conf stays the way to get a running mission today, but it is a
workaround: it disables the cockpit's primary input device.

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

emulator/render-bridge/podrun.sh

@@ -82,6 +82,13 @@ export VPX_DUMPDIR="$WORK"
 export VPX_NOMAIN=1
 export VPX_CLEAR=0,0,0
 export RIO_TAP="$WORK/riotap.txt"
+#
+# Board stream capture.  Without these the run renders but leaves nothing
+# to look at afterwards, which on a four-minute rig means re-running just
+# to see a frame.  FIFOSOCK also lets the render bridge attach live.
+#
+export VPX_FIFODUMP="$WORK/live.fifodump"
+export VPX_FIFOSOCK=8621
 
 rm -f "$BR/podlog.txt"
 cd /c/VWE/TeslaRel410/emulator/src/src