BT410: correct the leak-gauge note -- both of my guesses about it were wrong

The CFG parameter order is fine (Make already maps third/frames by name,
with a comment saying so), and we do not paint nothing: cropping the plane
shows both binaries draw the hatch, ours about three columns narrower.  So
it is a level/frame-width detail, and most likely the same root as the
coolant numerals -- our coolant value differing by a step.  Folded the two
into one thread and pointed it at the value rather than the widget.

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

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

@@ -905,17 +905,20 @@ WHAT IS STILL OPEN, IN THE ORDER I WOULD TAKE THEM:
      climb, and the last one.
 
   2. The leak-gauge hatch (~480px, and the bulk of what is left on Heat and
-     the MFDs).  Shipped paints a small hatched block at the foot of every
-     LEAK column; ours paints nothing.  At zero leak BitMapInverseWipe takes
-     its level<1 branch and draws frame 0 in colorA -- and colorA is 0 at
-     every call site, cluster and CFG alike.  Worth checking the CFG
-     parameter order before touching the widget: the config passes
-     LeakGauge(port, mode, eleak.pcc, 0, 255, 3, .15, @6), i.e. TWO values
-     between the colours and the attribute, while our ctor takes
-     (color_a, color_b, third_in, frames_in, value) with the cluster sites
-     passing third=0, frames=3.  If Make maps those positionally the .15 and
-     the 3 may be landing in the wrong parameters, which would also explain
-     fullWidth clamping every level to 0.
+     the MFDs).  CORRECTED after checking both of my own guesses:
+
+       - The CFG parameter order is NOT the problem.  BitMapInverseWipe::Make
+         already maps parameter 6 -> third and 5 -> frames BY NAME, with a
+         comment saying parse-order != arg-order.  It is right.
+       - We do NOT paint nothing.  Cropping the plane shows BOTH binaries
+         draw the hatch; ours is about three columns narrower and sits three
+         pixels right, missing the leftmost stripe.
+
+     So this is a LEVEL or frame-width detail, not a missing draw -- and the
+     likeliest root is the same one as (3): our coolant value differs
+     slightly from the shipped model's, which moves the wipe by a step.
+     Treat (2) and (3) as one thread and start from the VALUE (log the
+     gauge's coolantDraw against the shipped display's), not from the widget.
 
   3. The COOLANT A / S numerals on the Heat head (shipped reads 300 and 33x;
      ours differ) -- a heat-model value question, not a rendering one.