BT410 5.3.53: full spec for the mech-skeleton brick, with an exact success criterion

Everything needed to write the .SKL -> dpl_DCS path is now known and written
down: the file format (each page = one node with a local transform, an
optional .bgf, damage-zone tags and its child joint pages), the dPL call set
(NewDCS / SetDCSMatrix / AddDCSToDCS / LoadObject / NewInstance /
AddInstanceToDCS / FlushDCS), and the algorithm matching RPL4VID.HPP's
ReadSKLFile + RecurseSKLFile, including where DPLJointToDCSTranslator picks
up the joint->DCS mapping afterwards.

One unknown is flagged honestly: no surviving source calls dpl_SetDCSMatrix
(the RP game file that did is missing, like BT's), so the matrix convention
must be derived from the dpl3-revive protocol spec and DPLTYPES.H.

The success criterion is exact and needs no pixels: the dpl3-revive reference
capture of a real pod decodes as 26 DCS flushes and 22 instance flushes, and
MAD.SKL declares JointCount=25 (+root = 26) with DZoneCount=22.  A correct
walk of that one file should reproduce those counts on the wire.

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

restoration/source410/RENDER-ROADMAP.NOTES.md

@@ -621,3 +621,62 @@ answer MechClassID (3001) by reading the .SKL notation pages (VIDEO/*.SKL are
 in the mount) into a dpl_DCS hierarchy and hanging the per-node .BGF geometry
 off it -- ReadSKLFile + RecurseSKLFile per the sibling header, content from
 the BT411 donor.
+
+================================================================================
+SPEC FOR THE NEXT BRICK: the mech skeleton (.SKL -> dpl_DCS tree)
+================================================================================
+Everything needed to write it is now known.  Written down so the next session
+is mechanical rather than exploratory.
+
+THE FILE FORMAT (VIDEO/MAD.SKL, a plain NotationFile):
+
+    [DamageZones]          dz_dtorso=0 ... dz_utorso=21   (22 of them)
+    [ROOT]                 JointCount=25  DZoneCount=22
+                           tranx/trany/tranz  pitch/yaw/roll
+                           joint=jointlocal   joint=jointshadow
+    [jointlocal]           parent=ROOT  Type=balltranslate
+                           tranx.. pitch..   joint=jointhip joint=jointlthigh ...
+    [jointhip]             parent=jointlocal  Type=hingex
+                           Object=mad_hip.bgf         <- the geometry
+                           dzone=dz_hip               <- damage-zone tags
+                           tranx.. pitch..  joint=jointtorso  site=siteedz_hip
+
+So each page is one node: a local transform, an OPTIONAL .bgf object, zero or
+more damage-zone tags, and its child joint page names.  Type= is the joint
+kind (ball / balltranslate / hingex / hingey) and matters for animation, not
+for the initial build.
+
+THE dPL CALLS (CODE/RP/MUNGA_L4/libDPL/dpl/DPL.H):
+
+    dpl_NewDCS()                        create a transform node
+    dpl_SetDCSMatrix(d, float32 *m)     its 4x4 matrix
+    dpl_AddDCSToDCS(parent, child)      parent it
+    dpl_AddDCSToScene(d)                root it
+    dpl_SetDCSZone(d, zone)             assign the zone (MakeNewZone gives one)
+    dpl_LoadObject(name, dpl_load_normal)
+    dpl_NewInstance() / dpl_SetInstanceObject(i,o) / dpl_AddInstanceToDCS(d,i)
+    dpl_FlushDCS(d)                     push it to the card
+
+THE ALGORITHM (matches RPL4VID.HPP's ReadSKLFile + RecurseSKLFile):
+  ReadSKLFile: open the .SKL as a NotationFile, make the zone, recurse "ROOT".
+  RecurseSKLFile(page, parentDCS):
+    1. read tranx/y/z + pitch/yaw/roll -> a matrix -> dpl_NewDCS + SetDCSMatrix
+    2. parent it (AddDCSToDCS, or AddDCSToScene at the root)
+    3. if Object= -> dpl_LoadObject, dpl_NewInstance, SetInstanceObject,
+       AddInstanceToDCS   (Entity_Being_Created is already set by the caller so
+       the C callback can tag geometry with damage zones -- see L4VIDEO.CPP:4176)
+    4. record dcs_array[segment index] so DPLJointToDCSTranslator (L4VIDEO.CPP:
+       6326) can map joint -> DCS afterwards
+    5. for each joint= child, recurse
+
+THE ONE UNKNOWN: the exact dpl_MATRIX layout/convention.  No surviving source
+calls dpl_SetDCSMatrix -- the RP game file that did is missing, like BT's.
+Derive it from dpl3-revive/spec/VELOCIRENDER_PROTOCOL.md, which decodes DCS
+bodies as "type 5 (dcs), 4x4 dpl_MATRIX each", and from DPLTYPES.H.
+
+SUCCESS CRITERION, and it is exact.  The dpl3-revive reference capture of a
+real pod decodes as "Transforms: flush bodies type 5 (dcs) x26" and
+"Placements: type 4 (instance) x22".  MAD.SKL declares JointCount=25 (+1 root
+= 26) and DZoneCount=22.  So a correct walk of this one file should put 26 DCS
+flushes and 22 instance flushes on the wire -- countable in the fifodump
+without looking at a single pixel.