#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/heat.cpp

@@ -1486,3 +1486,67 @@ void BTReportHeatAtReset(void *mech_v)
 						<< "\n" << std::flush;
 	}
 }
+
+//===========================================================================//
+// BTReportMyomerFreeze -- #137 forensic (BT_HEAT_LOG), the POST-reset trace.
+//
+// BTReportHeatAtReset samples AT the reset and showed every subsystem at
+// T == startingTemperature, which is what made the reset path look innocent and
+// got #137 wrongly closed.  The field then proved the freeze is real (5 of 61
+// respawns: throttle up, speedDemand pinned at 0) -- so the interesting window
+// is the frames immediately AFTER the reset, which nothing was sampling.
+//
+// Three explanations survive the decomp read and only data separates them:
+//   (a) RESET DIDN'T TAKE    -> temp is high right after the reset
+//   (b) STALE CACHE          -> temp is at start but speedEffect is still 0
+//                              (HeatSink::RTIS @004ad760 writes only bytes
+//                               0x114/0x12C/0x130/0x134/0x138/0x158/0x15C --
+//                               it does NOT touch Myomers::speedEffect @0x31C,
+//                               and Myomers::RTIS @004b8aa4 only chains to the
+//                               PoweredSubsystem one, so the pre-death value
+//                               survives until the myomers next ticks)
+//   (c) INSTANT RE-HEAT      -> temp starts at start and climbs back at once
+//
+// Prints per myomers: temperature, its own speedEffect, and the mech-level MAX
+// the mover actually multiplies by.  Freeze == that MAX at 0.
+//===========================================================================//
+void BTReportMyomerFreeze(void *mech_v, const char *when)
+{
+	if (mech_v == 0 || getenv("BT_HEAT_LOG") == 0)
+		return;
+	Entity *mech = (Entity *)mech_v;
+	extern Scalar BTMyomersSpeedEffectOf(void *subsystem);
+	const int count = mech->GetSubsystemCount();
+	Scalar best = -1.0f;
+	for (int i = 0; i < count; ++i)
+	{
+		Subsystem *s = mech->GetSubsystem(i);
+		if (s == 0)
+			continue;
+		Scalar f = BTMyomersSpeedEffectOf(s);
+		if (f < -0.5f)
+			continue;							// not a Myomers
+		if (f > best) best = f;
+		Scalar t = -1.0f, tdeg = -1.0f, tfail = -1.0f;
+		if (s->IsDerivedFrom(*HeatableSubsystem::GetClassDerivations()))
+		{
+			HeatableSubsystem *h = (HeatableSubsystem *)s;
+			t     = h->currentTemperature;			// @0x114
+			tdeg  = h->degradationTemperature;		// @0x118
+			tfail = h->failureTemperature;			// @0x11C
+		}
+		// The derating curve (@004b8ac0) is exactly:
+		//   temp >= degradation -> falls off;  temp >= FAILURE -> 0.0 (frozen).
+		// So printing the thresholds beside the temperature says immediately
+		// whether a 0 effectiveness is JUSTIFIED by the temperature (reset did
+		// not take / re-heated) or is a STALE cache (temp fine, effect still 0).
+		DEBUG_STREAM << "[myofreeze] " << when << "  " << (s->GetName() ? s->GetName() : "?")
+			<< "  T=" << t << " deg=" << tdeg << " fail=" << tfail
+			<< "  speedEffect=" << f
+			<< (f <= 1.0e-4f && t < tfail ? "   <<<< STALE (cold but zero)" : "")
+			<< "\n" << std::flush;
+	}
+	if (best >= 0.0f)
+		DEBUG_STREAM << "[myofreeze] " << when << "  CHAIN MAX=" << best
+			<< (best <= 1.0e-4f ? "   <<<< FROZEN" : "") << "\n" << std::flush;
+}