BT410 5.3.40: correction -- the 'exact' heads are exact only on lucky runs

Same binary (md5 identical), different run: Eng1/Eng2/Comm read
17981/17981/15656 on some runs and 19011/19011/16909 on others.  The shipped
binary is STABLE across three runs, so this is ours.  Eleven consecutive
clean runs is what let it hide, and the dirty numbers are exactly the
pre-gate numbers from 5.3.32 -- the same artifact recurring.

Read off the raw words rather than inferred: in the artifact rect the shipped
binary writes ONE masked plane bit per pixel (0x4000 = Heat, 0x002D = sec),
while we write arbitrary 16-bit words (0x8BD6 / 0x8AD6 / 0x8AC0) that light
sec+overlay+Mfd1+Eng1+Eng2+Comm at once.  Raw values going into a
plane-packed buffer -- which is why one bad draw appears as extra pixels on
six heads and as 483 MISSING on Heat at the same time.

Intermittent because these widgets are change-driven: on runs where the
coolant value never moves after the first paint, the bad draw never happens.

The six fixes of 5.3.33-39 stand (each moved specific attributable pixels).
What must be restated is the claim that four heads are exact -- true only
when this defect does not fire.  The rig now needs a run-variance check
before any per-head number is believed.

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

restoration/source410/BT_L4/BTL4GAU2.CPP

@@ -2027,6 +2027,8 @@ SubsystemCluster::SubsystemCluster(
 				<< " placement=" << clusterPlacement
 				<< " bg='" << (clusterBackgroundName ? clusterBackgroundName : "(none)")
 				<< "' port=" << mfd_port
+				<< " engPortName='" << (eng_port_name ? eng_port_name : "(null)")
+				<< "' engPort=" << renderer_in->FindGraphicsPort(eng_port_name)
 				<< " x=" << x << " y=" << y
 				<< " title='" << (title ? title : "(null)")
 				<< "' banner=" << (titleBanner ? 1 : 0) << "\n" << flush;

restoration/source410/BT_L4/GAUGE-BLOCK.NOTES.md

@@ -936,3 +936,58 @@ WHAT IS STILL OPEN, IN THE ORDER I WOULD TAKE THEM:
 
   4. MFD remainders: ~270 missing / ~34 extra across the three heads, mostly
      the same leak hatch as (2).
+
+================================================================================
+5.3.40 -- A CORRECTION: the "exact" heads are exact only on lucky runs
+================================================================================
+THE HEADLINE NUMBERS IN 5.3.39 ARE MEASURED ON RUNS WHERE AN INTERMITTENT
+DEFECT DID NOT FIRE.  Same binary (md5 verified identical), different run:
+
+    run              Eng1     Eng2     Comm
+    big/own/arc      17981    17981    15656     <- matches shipped exactly
+    t_a/t_b/t_c      19011    19011    16909     <- +1030 / +1030 / +1253
+    shipped x3       17981    17981    15656     <- STABLE across three runs
+
+The shipped binary does NOT vary; ours does.  So this is our defect, it is
+per-RUN (stable across captures 75s apart within a run, decided by the time
+of the first capture at +60s), and the dirty numbers are EXACTLY the pre-gate
+numbers from 5.3.32 -- the same artifact recurring, not a new one.  Eleven
+consecutive clean runs followed by dirty ones is what let it hide.
+
+WHAT IT ACTUALLY IS -- read off the raw words, not inferred.  In the artifact
+rect (fb x 526..538, y 228..279, a 13x52 vertical bar = the coolant column):
+
+    shipped writes   0x4000 = Heat          0x002D = sec        0x0500 = Mfd1+Mfd2
+    ours writes      0x8BD6 / 0x8AD6 / 0x8AED / 0x8AC0
+                     = sec + overlay + Mfd1 + Eng1 + Eng2 + Comm, all at once
+
+Shipped writes ONE masked plane bit per pixel.  We write arbitrary 16-bit
+words that light six planes at once -- raw values going into a plane-packed
+buffer.  That is why a single bad draw shows up as "extra pixels" on Eng1,
+Eng2, Comm, overlay, sec AND Mfd1 simultaneously, and why Heat is
+simultaneously MISSING 483 (the bit that should have been set there never
+was).  The A-button garble at (67..99, 3..34) is the same failure in a second
+spot; the clusters at 113/102/69/36/34 px are its fragments.
+
+WHY INTERMITTENT: these widgets are CHANGE-DRIVEN (they redraw only when
+their value moves).  On runs where the coolant value never moves after the
+first paint, the bad draw never happens and the head reads exact.  On runs
+where it moves, the garbage lands and nothing ever erases it.
+
+WHAT THIS DOES AND DOES NOT INVALIDATE:
+  * The six FIXES of 5.3.33-39 are real and independently measured -- the
+    MissileLauncher tables, the strip art, the ammo feed, the loop lamp, the
+    arc span and the Comm own row all moved specific, attributable pixels.
+  * The CLAIM "Eng1/Eng2/Eng3/Comm are exact" is only true on clean runs.
+    Restate it as: exact when the plane-write defect does not fire.
+  * The rig needs a RUN-VARIANCE check before any per-head number is
+    believed.  Shipped is stable, so a shipped baseline can be captured once;
+    ours must be captured at least twice and the counts compared.
+
+NEXT STEP: find the write path that emits an unmasked word.  Both known
+instances are on the Heat/coolant column and the generator-select button, and
+the engPort resolution is NOT the cause (traced: eng1/eng2/eng3 resolve
+correctly to 3/5/7).  Suspect the tile/strip blit for VertTwoPartBar-family
+widgets writing tile pixel VALUES rather than using them as a mask with the
+port colour -- the same widget draws correctly on the MFD heads, so it is
+specific to this port or this call site.