Fix Rifleman MFD/Radar damage mappings; document the authoring pipelines

Repairs Rifleman's external MFD and Radar paper-doll source rectangles,
removes the dead commented-out Dasher rows, and records the canonical
authoring pipelines that had never been written down.

Requires a Windows VC6 Release/Profile rebuild - DXRasterizer.cpp
includes coord.cpp directly - plus a physical MFD/Radar hardware test.
The Linux workflow validates data and geometry only.

How the mapping was validated
-----------------------------
Ground truth is Mad Cat (ID 40), whose mapping is known-good in game and
user-confirmed. It establishes the invariant:

  texuv2/texuv3 rectangles must bound the component blobs in the runtime
  BMP, and the rule is exact - texuv = blob bounding box with x1,y1 + 1.

offset2/offset3 are on-screen placement and deliberately do NOT align to
the BMP; overlaying them against the art is meaningless.

Scoring each rectangle by IoU against the nearest art blob gives a clean
bimodal split: healthy chassis 0.78-0.99 (the single sub-0.5 zone is
normally HD, which has no blob of its own), broken chassis below 0.5.

Rifleman
--------
Its texuv2 row was a verbatim copy of Mad Cat's, so CT landed in empty
space, S1/S2 enclosed nothing and the legs hung off the art. Its texuv3
row was independently misaligned.

  MFD    0.14  -> 0.86
  Radar  0.25  -> 0.87
  (Mad Cat control, unchanged: 0.88)

Zone labels were confirmed by eye, not inferred - an automatic classifier
trained on the 42 healthy chassis reproduces only ~70% of labels, because
zone placement is conventional but not guaranteed. HD is the small 3-bar
element under the centre torso, recovered by merging three sub-300px
fragments that the blob threshold had discarded.

Note the Radar layout is NOT a mirror of the MFD one: the legs move up
into the middle row and the wide S1 slab moves from the top to the
bottom. Radar S2 is now zeroed; the previous {186,10,312,78} had no
corresponding art.

Dasher rows
-----------
Dropped the four commented-out M_Dasher rows from all four arrays. Dasher
is not in the 65-ID roster, and a commented row is an active hazard: any
tool that parses these arrays or texturename[] without stripping comments
first picks it up and shifts every later chassis by one. That exact bug
produced a bogus "id41 madcat" during this work.
(huddamage.cpp still has a commented "hud\\dasher" entry - same hazard,
left for a separate change.)

MFD-RADAR-MAPPINGS.md
---------------------
Adds the project owner's verbatim MFD and Radar authoring pipelines as
the authority, plus the fact that coord.cpp is edited via the GameOS
project's "External Dependencies" folder in the VC6 IDE.

Records the distinction that caused a wrong diagnosis during this work:
Radar expands its canvas to 512 BEFORE the unexploded view is saved, so
Radar coordinates are measured in 512 space, whereas MFD expands to 512
AFTER all coordinates are recorded, so MFD coordinates are in 340 space.
Also MFD separates sections with a 4x4 black line while Radar outlines
with 2x2 white, both rectangles are measured on the unexploded view, and
the exploded view saved in indexed mode is the runtime BMP.

File remains CRLF-only; all four arrays verified at 65 rows x 11 zones.

Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>

MFD-RADAR-MAPPINGS.md

@@ -23,6 +23,12 @@ into a mech texture atlas. They are not the 512x512 damage-mask images mapped by
 
 ## Controlling code
 
+The file to edit is `Gameleap/code/CoreTech/Libraries/GameOS/coord.cpp`. In the VC6 IDE it is
+not a listed source file of any project: it appears under the **GameOS project's "External
+Dependencies" folder**, because `DXRasterizer.cpp` `#include`s it directly. Open it from there
+(or from disk). Because it is an include, editing it requires rebuilding the game executable,
+not merely relinking.
+
 `coord.cpp` defines four positional arrays:
 
 ```cpp
@@ -91,6 +97,70 @@ Black Hawk Radar RT `x=85`. Radar's integer `/2` truncates odd values at runtime
 odd authored value can move an edge or origin in the rendered 256x256 view. Work from the
 upper-left to lower-right of each component, and do not overlap source rectangles.
 
+## Canonical authoring steps
+
+This is the project owner's own specification of the two pipelines, recorded verbatim. It is the
+authority. The expanded prose sections that follow explain and justify these steps but must not
+contradict them.
+
+### MFD (verbatim)
+
+```text
+take 1024 image
+reduce image to 320
+expand canvas to 340 (centered)
+Using a 4x4 black line seperate the sections
+***save as unexploded***
+split components (no overlaps from upper left to lower right of component)
+record coords from upper left to lower right, use even numbers.
+(x,y,x1,y1)
+Now using the Unexploded view (image in upper left corner) overlay the exploded pieces
+and record the upper left corner coord.
+(x2,y2)
+expand canvas to 512x512 (upper left corner)
+Save the exploded view in Index Mode.
+
+Modify file(s):
+coord.cpp (under GameOS/External dependancies)
+```
+
+### Radar (verbatim)
+
+```text
+take 1024 image
+reduce to 400
+expand canvas to 410 (centered)
+expand canvas to 512 (upper left corner)
+***Save this as Unexploded View***
+split components (no overlaps from upper left to lower right of component)
+Outline components in white 2x2 pixel
+record coords from upper left to lower right, use even numbers.
+(x,y,x1,y1)
+Now using the Unexploded view (image in upper left corner) overlay the exploded pieces
+and record the upper left corner coord.
+(x2,y2)
+Save the exploded view in Index Mode.
+
+Modify file(s):
+coord.cpp (under GameOS/External dependancies)
+```
+
+### Points that are easy to lose
+
+- The two pipelines differ in **when** the canvas becomes 512. Radar expands to 512 **before**
+  the unexploded view is saved, so Radar coordinates are measured in 512 space. MFD expands to
+  512 **after** all coordinates are recorded, so MFD coordinates are measured in 340 space.
+- MFD separates sections with a **4x4 black line**; Radar outlines components with a **2x2 white
+  line**. These separators exist so no source rectangle can bleed into a neighbouring component.
+- Both `(x,y,x1,y1)` rectangles are measured on the **unexploded** view, never on the exploded
+  BMP.
+- `(x2,y2)` is recorded by keeping the unexploded view in the upper-left and laying the exploded
+  pieces over that same canvas, so offsets share the unexploded coordinate space.
+- The exploded view is saved in **indexed color mode**. That saved exploded 512x512 image is the
+  runtime BMP.
+- Prefer even numbers when recording, but never round an odd value that has already been
+  visually validated.
+
 ## MFD authoring pipeline
 
 Start with the finished 1024x1024 full-color 'Mech image.