#137: REPRODUCE the myomer freeze -- reset is innocent, the myomers RUN AWAY after it

First reproduction of #137 in a bench.  The reset path is exonerated and the
real defect is located, though not yet explained.

DECOMP RE-READ (what the reset actually does):
  Mech::Reset @0049fb74 walks the roster from index 2 calling vtable +0x28
    (slot 10 = ResetToInitialState), then @0049f788.
  Myomers::RTIS @004b8aa4 -> PoweredSubsystem::RTIS @004b0e6c -> ALWAYS
    HeatSink::RTIS @004ad760, whose first act is
        param_1[0x45] = param_1[0x4f]     // currentTemperature = startingTemperature
    (byte 0x114 = 0x13C).  Our port matches AND additionally resets heatEnergy,
    which it must, since HeatSinkSimulation derives
        currentTemperature = heatEnergy / thermalMass.
  The freeze itself is the derating curve @004b8ac0:
        temp >= degradation(@0x118) -> falls off
        temp >= FAILURE(@0x11C)     -> 0.0  -> chain MAX 0 -> speedDemand *= 0.
  Nothing in the reset chain touches Myomers::speedEffect (@0x31C).

MEASURED (scratchpad/night14/myofreeze.sh -- hot mech, repeated self-kill):

    at-reset   Myomers T=77      deg=1000 fail=2000  speedEffect=0   <- stale
    post-reset Myomers T=77.14                        speedEffect=1   <- 1 frame
    post-reset Myomers T=9297.8  fail=2000            speedEffect=0
    post-reset Myomers T=11620.4 fail=2000            speedEffect=0

So, in order:
  * THE RESET WORKS.  T is exactly startingTemperature at the reset.  My
    original bench was right about that much; it just stopped looking there.
  * THE STALE speedEffect IS REAL BUT HARMLESS -- it survives the reset (no
    RTIS writes it) yet self-heals on the very next tick.  Not the bug.
  * THE MYOMERS THEN RUN AWAY: 77 -> ~11,600 against a FAILURE point of 2,000,
    nearly 6x over, in seconds.  That is not heat earned by running; that is a
    runaway, and it is what pins speedDemand at 0 until it cools -- exactly
    Oracle's "maxed heat bar ... unable to move until it cools off".
  * Rate: 7 of 105 census samples over the failure temp (~6.7%), against the
    field's 5-of-61 respawns (~8%).  Same order, so the bench is reproducing
    the field condition and not a bench artifact.
  * The myomers link to Condenser5 (mass=250000 k=190000) -- literally Oracle's
    "loop 5 and generator D heating up as all the excess heat goes into the loop".

NOT YET ESTABLISHED, and the reason this is a checkpoint and not a fix: whether
the runaway is CAUSED by the respawn or is a heat-model calibration problem that
merely CORRELATES with it (you die when you overheat, so respawns cluster around
hot periods).  The bench drives at 95% throttle with continuous missile autofire,
which is abusive, and the [heat-t] census has no pre-first-reset samples to
compare against.  Next step is to instrument the heat INPUT and diff a
respawn-adjacent window against a steady-running window.

Probe added: [myofreeze] prints T / degradation / FAILURE / speedEffect per
myomers plus the chain MAX the mover multiplies by, AT the reset and for ~4 s
after (armed by Mech::Reset, sampled where the multiplier is formed).  The
post-reset window is what nothing was watching -- sampling only at the reset is
what made this look innocent and got the ticket wrongly closed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018SgmXGNMXavXiafKXf9MDC

game/reconstructed/mech4.cpp

@@ -666,6 +666,7 @@ static int          gBTPPCKey         = 0;
 static int          gBTMissileKey     = 0;
 static int          gBTPinkyKey       = 0;	// key '4' = the pod's 4th fire button (Pinky 0x45)
 int                 gBTModeCycle      = 0;	// 'M' edge: cycle the control mode (mapper consumes)
+int                 gBTMyoTrace       = 0;	// #137: frames of post-reset myomer tracing left (armed by Mech::Reset)
 int                 gBTDisplayCycle   = 0;	// 'N' edge: cycle the secondary schematic (Gitea #6, mapper consumes)
 int                 gBTPresetCycle[3] = {0,0,0};	// J/K/L edges: cycle an upper-MFD preset page (Gitea #9, L4 mapper consumes)
 //
@@ -2379,6 +2380,14 @@ void
 	{
 		extern void BTReportHeatAtReset(void *mech_v);
 		BTReportHeatAtReset((void *)this);
+		// #137: sample the myomers AT the reset, and arm the POST-reset trace.
+		// Sampling only here is what got this bug wrongly closed -- every
+		// subsystem reads T == start at this instant, which looks innocent.
+		// The freeze shows up in the frames AFTER.
+		extern void BTReportMyomerFreeze(void *mech_v, const char *when);
+		extern int  gBTMyoTrace;
+		BTReportMyomerFreeze((void *)this, "at-reset");
+		gBTMyoTrace = 240;			// ~4 s of post-reset frames
 	}
 
 	// --- DESKTOP THROTTLE RELEASE (#146) -- PORT LAYER, desktop-only ---------