BT410 5.3.56: the intermittent pod crash is the skeleton walk's -- attributed by same-binary A/B

Added BT_NO_SKL, which skips the skeleton build so ONE executable can be run
with and without it.  That is the only clean way to test an intermittent
fault, and it settles attribution:

  walk enabled   ~50% of runs die (page fault at 66D9) at DIFFERENT points
  walk disabled  0 crashes in 2 runs
  shipped exe    0 crashes in 2 runs, same rig and conf

So it is our new code, not the rig, and the varying fault point points at
memory corruption surfacing later rather than a bad instruction in the walk.

Hypotheses killed by reading the private library headers: the matrix array is
the right size (dpl_MATRIX is float32[4][4]); and neither s_dplobject nor the
common dpl_node header retains an object name, weakening the dangling-string
theory (a private name cache inside the library is still possible and is the
best surviving suspect).

Also checked something that would have been much worse than a crash:
~NotationFile REWRITES its file when dirty, and these are the game's shipped
.SKL data files.  MAD.SKL is untouched, and ReadSKLFile now carries the
engine's own Verify(!IsDirty()) guard.

Next tests are listed cheapest-first in the roadmap: keep the NotationFile
alive, copy the Object= names, count board allocations, and re-check whether
MakeEntityRenderables runs twice per mech.

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

emulator/render-bridge/podlog.txt

@@ -8,7 +8,6 @@ ColorMapperArmor warning: damage zone dz_lmissle not found
 ColorMapperArmor warning: damage zone dz_rmissle not found
 ColorMapperArmor warning: damage zone dz_ftorso not found
 ColorMapperArmor warning: damage zone dz_btorso not found
-L4VIDEO.cpp wrong video resource type for object mad.skl
 BTL4Application::RunMissionMessageHandler
 Turning Plasma Score Display On
 BTL4Application::RunMissionMessageHandler