BT410 5.3.86: colour-mapper escalation KILLED -- they read palettes, they never blit

5.3.85 raised a hypothesis and explicitly flagged it as unverified: the 1345
colour-mapper entries (656 cmCrit, 662 cmHeat, 27 cmArmor) all sit on port 0,
their mode is ModeSecondaryCritical, and they name adpal.pcc / adpal2.pcc /
heatpal.pcc -- three files the art sweep flags, with ADPAL and ADPAL2 being 2x5
and ENTIRELY index 99.  If those pixels were blitted as colour indices, 1345
widgets would each be writing out-of-range on the six-bit head, which would
dwarf the 676px bar and would fire in-mission, exactly where the operator sees
the artifact.

Read the implementation.  It does not happen.

ColorMapper::ColorMapper (BTL4GAUG.CPP:389) takes the two names into the
palette8Bin -- not a pixelmap bin, not a bitmap bin -- and the execute path
(:526) is

    Palette8 *palette = warehouse->palette8Bin.GetIfAlreadyExists(...);
    PaletteTriplet &entry = palette->Color[currentColorIndex];
    ...
    graphicsPort->SetColor(&entry, colorSlot);

It reads the file's VGA PALETTE, lifts one RGB triple, and pushes it into a
hardware colour slot.  No pixel of ADPAL ever reaches a framebuffer, so its
index-99 content cannot matter.  The palette PAIR is a flash toggle
(paletteToggle alternates per frame), which is also what twoColorMode's
name comparison is for.

NEGATIVE.  Recorded as a closed hypothesis rather than deleted, so it does not
get re-raised the next time somebody greps the sweep and sees ADPAL at 100%
out-of-range.

What this leaves: the in-mission exposure, if there is one, is NOT the
mappers.  The *CRIT/*HEAT silhouettes still carry 1500-2500px of index 231
each, and which widget blits them is still unestablished.  The boot cockpit
does not draw them, which is why it lights only 1030 pixels.

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

restoration/source410/MUNGA_L4/L4GREND.NOTES.md

@@ -75,24 +75,43 @@ out: it is an inert stub returning NULL, so `recoloredMech` never blits in our
 build. Unattributed. The fix covers it either way, since it zeroes the whole
 tail regardless of who indexes it.
 
-**The colour mappers may be a second exposure, in-mission.** `L4GAUGE.CFG`
+That the boot cockpit lights only 1030 pixels says the avatar art is not being
-carries **1345** colour-mapper entries — 656 `cmCrit`, 662 `cmHeat`, 27
+drawn on that screen. It does not say anything about a live mission — the
-`cmArmor` — and `BT_VIS_LOG` puts all of them on **port 0**, the six-bit head,
+`*CRIT`/`*HEAT` silhouettes carry 1500–2500 pixels of index 231 apiece, so if
-at 50,0. Their mode is literally `ModeSecondaryCritical`. They name
+something blits them on port 0 the in-mission artifact is several times the
-`adpal.pcc`, `adpal2.pcc`, `heatpal.pcc`, `heatpal2.pcc`, three of which the
+size of the bar. Which widget blits them is not yet established.
-sweep flags as out-of-range (`ADPAL`/`ADPAL2` are 2×5 and **entirely** index
-99; `HEATPAL` has one pixel at 100).
 
-Whether that matters depends on something not yet established: these are tiny
+## Closed hypothesis: the colour mappers are NOT a second exposure
-swatch files, and a colour mapper plausibly reads their **VGA palette** rather
-than blitting their pixels. Do not repeat this as a finding until someone has
-read the mapper's implementation. It is recorded because if the pixels *are*
-used as colour indices, every one of 1345 mappers writes an out-of-range index
-on the six-bit head — which would dwarf the 676px bar and would fire
-in-mission, matching where the operator sees the artifact.
 
-That the boot cockpit lights only 1030 pixels says the avatar/mapper art is not
+Recorded because it was raised as a serious escalation and then killed, and the
-being drawn on that screen. It does not say anything about a live mission.
+kill is worth keeping so nobody re-raises it.
+
+The worry: `L4GAUGE.CFG` carries **1345** colour-mapper entries — 656 `cmCrit`,
+662 `cmHeat`, 27 `cmArmor` — `BT_VIS_LOG` puts every one of them on **port 0**,
+their mode is literally `ModeSecondaryCritical`, and they name `adpal.pcc`,
+`adpal2.pcc`, `heatpal.pcc`, three of which the sweep flags (`ADPAL`/`ADPAL2`
+are 2×5 and **entirely** index 99). If those pixels were blitted as colour
+indices, 1345 widgets would each be writing out-of-range on the six-bit head.
+
+They are not blitted. `ColorMapper::ColorMapper` (`BTL4GAUG.CPP:389`) takes the
+two names into the **`palette8Bin`**, not a pixelmap or bitmap bin, and the
+execute path (`:526`) is
+
+```c
+Palette8 *palette = warehouse->palette8Bin.GetIfAlreadyExists(paletteName[paletteToggle]);
+PaletteTriplet &entry = palette->Color[currentColorIndex];
+...
+graphicsPort->SetColor(&entry, colorSlot);
+```
+
+It reads the file's **VGA palette**, takes one RGB triple, and pushes it into a
+hardware colour slot. No pixel of `ADPAL` ever reaches a framebuffer, so their
+index-99 content is irrelevant. The two-palette pair is a flash/toggle
+(`paletteToggle` alternating each frame), which is also why `twoColorMode`
+compares the two names.
+
+**Conclusion: negative.** The mappers are not an exposure, and the search for
+the in-mission source has to go elsewhere.
 
 ## A shipped data bug, found in passing — do NOT fix