BT410 5.3.120: the mech ducks -- the master perf's duck driver landed whole, and the collision cylinder breathes with it

The first block reconstructed from the isolated master performance
(@004a9f61..@004aa155, instruction-level read of the ndisasm listing), and
with it the Mech's authentic message roster straight from the binary's own
handler table: RealMaxSpeed 0x15, BalanceCoolant 0x16, SetBurningState
0x17, ClearBurningState 0x18, EjectPilot 0x19, DuckRequest 0x1A -- the
enum now exists in MECH.HPP with those names.

The system end to end: a DuckRequest message (@0049fa00) latches ONE
evaluation -- the latch is consumed every master frame and cleared by
Reset. The phase machine reads the raw simulation state, the mapper's
duck button cell and the analog demand (deadzone 1e-4): from gait 0/4 it
arms the sqd clip on the LEG channel only (slot 2 -- the slot map, not
the enum's walk names), from the ducked hold it arms squ (slot 3), and a
mech that starts limping while ducked is stood up by force. The
collision-volume alarm (level 1 standing / 0 ducked, guarded by the
authentic "Whoa! Bad Collision Volume State!") swaps the collision
template's maxY -- the box TOP; the ground probe's minY is untouched --
between the ctor-captured height and 0.6x it (the double at @004a2d38).
duckState publishes for the cockpit's crouch selector.

Live-verified end to end: BT_FORCE_DUCK (an authentic press every 4s on
its own clock) cycles press -> sqd -> volume 9.91->5.94 -> ducked hold ->
press -> squ -> standing, continuously, no faults. En route the test
machine-checked three neighbors for free: the squat clips resolve and
play at the idle rate, the clip-finish transitions for slots 2/3 fire,
and the machine correctly REFUSES to duck while walking (legState 5).

Deferred, recorded: the per-arm MarkUpdate masks (8, 1) ride the
still-empty ForceUpdate (the MP update-record feed), and the mapper duck
cell's streamed binding id awaits a BT_MAP_LOG audit.

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

emulator/render-bridge/pod_render_duck.conf

@@ -0,0 +1,85 @@
+# pod_render_norio.conf -- pod_render_rec with the RIO serial port OFF.
+#
+# The emulator log shows a steady stream of serial1 RX OVERRUN errors on
+# the RIO pipe, and controls post their events at HighEventPriority
+# UNCONDITIONALLY (CONTROLS.HPP:250) -- so a chattering RIO port would
+# flood a priority the background pump always serves first, starving the
+# priority-0 renderer events the load gate waits on.  This conf tests that
+# by removing the port entirely.  Everything else is identical to the rec
+# conf, so a launch here and a hang there isolates the RIO.
+#
+[sdl]
+output=opengl
+# higher,higher not highest: HIGH_PRIORITY_CLASS starved the host desktop;
+# with the retry patches a rare dropout self-recovers (see gauge_rio.conf).
+priority=higher,higher
+[dosbox]
+memsize=32
+machine=svga_s3
+[cpu]
+core=dynamic
+cputype=pentium
+cycles=max
+[sblaster]
+sbtype=sb16
+sbbase=220
+irq=5
+dma=1
+hdma=5
+[mixer]
+# match the EMU8000s' native rate (no resample) and buffer ~60ms so brief
+# emulation-thread stalls (RIO retry recovery) don't audibly chop
+rate=44100
+blocksize=1024
+prebuffer=60
+[serial]
+# RIO on COM1 with the low-latency options (rxpollus/rxburst) so the board's
+# few-ms ACK deadline is met; plasma display on COM2 (real pod has both).
+# VWE fork namedpipe backend (com0com/realport retired -- COM1/COM2 gone):
+# DOSBox = pipe client (retry), vRIO/vPLASMA apps = servers; an unconnected
+# pipe behaves as an unplugged cable so the mission still runs. serialnamedpipe.h
+serial1=disabled
+serial2=namedpipe pipe:vplasma
+# live UNBUFFERED game output: DOS char devices are not buffered, so
+# redirecting stdout to COM3 lands every line immediately.  A normal
+# '> file' redirect stays 0 bytes until the process exits, which hides
+# all progress on a run that does NOT crash.
+serial3=file file:C:\VWE\TeslaRel410\emulator\render-bridge\podlog.txt
+[autoexec]
+mount c "C:\VWE\TeslaRel410\ALPHA_1"
+c:
+cd \REL410\BT
+set VIDEOFORMAT=svga
+rem production pod card init (PARAMETR.BAT:181-186): DIAGNOSE + AWEUTIL per
+rem card -- AWEUTIL /S does the EMU8000 bring-up and DRAM detect the HMI SOS
+rem driver relies on; skipping it left the cards uninitialized (silent).
+rem aweutil /s SKIPPED for now: it verifies the AWE32 GM ROM, which the
+rem emulated cards lack (hangs in a retry loop) -- restore once the ROM is
+rem dumped from a real card. diagnose /s kept (passes, sets mixer config).
+set BLASTER=A220 I5 D1 H5 P330 T6
+c:\sb16\diagnose /s
+set BLASTER=A240 I7 D3 H6 P300 T6
+c:\sb16\diagnose /s
+set BLASTER=A220 I5 D1 H5 P330 T6
+set TEMP=c:\
+rem arena1 city mission (TESTARN.EGG: map=arena1, time=day) with the RIO
+rem attached; stdout redirected so mission-load progress survives kills.
+set BT_JOINTS=1
+set L4VIEWEXT=1
+set BT_STACK_LOG=1
+set BT_MECH_LOG=1
+set BT_FORCE_DUCK=1
+set BT_GAUGE_LOG=1
+set BT_FORCE_THROTTLE=0
+set BT_FORCE_TURN=0
+set HEAPSIZE=15000000
+set L4GAUGE=640x480x16
+call setenv.bat r s n p
+32rtm.exe -x
+BTL4REC.EXE -egg testarn.egg > COM3
+
+echo GAME-RC=%errorlevel% >> RC.TXT
+32rtm.exe -u
+echo ALPHA1-RUN-DONE
+pause
+