#137 FIXED: restore the binary Reset's +0x58c re-seed -- the respawn freeze was a

teleport-poisoned finite difference, not heat, not the reset, not velocity

The one-line fix is the binary's own SECOND Reset instruction, dropped in
transcription:  FUN_00408440(mech+0x58c, param_2)  ==
    accelPrevPos = origin.linearPosition;
+0x58c is the previous-position memory of the AccelerationLastFrame ring feed
(+0x81c/0x824/0x828/0x82c).  The port reconstructed the ring faithfully (ctor
part_012.c:9836, derivative :15169) but Reset never re-seeded its cache, so the
first post-respawn sample computed |newPos - prevPos|/dt = TELEPORT DISTANCE/dt
(~1e5) into the velocity ring; the ring-mean derivative spiked
AccelerationLastFrame (pure forward, with an opposite-sign echo ~15 frames later
as the sample rotated out of the 15-ring); and the myomer integrator @004b8d18
turned it into a one-tick pendingHeat deposit of ~3e9:
    termAccel = (1-accEff) * |v| * |a| * m * dt
      = 0.2 * 40 * 1.04e5 * 75000 * 0.044  =  2.75e9
snapping the freshly-reset myomers from T=77 to T~9000 against failT=2000 ->
speedEffect 0 -> speedDemand *= 0 -> "respawned unable to move until it cools".

WHY ~8% IN THE FIELD: the deposit needs |v| in the same 1-2 frames, so only
pilots whose throttle was still forward at the respawn -- physical lever /
HOTAS, exactly who reported it -- had gait-republished speed in the spike
frames.  Idle-throttle respawns deposit ~nothing.  (And frozen-subset-of-
died-hot: died hot == was running hard == lever still forward.)

MEASURED, same abusive bench (0.95 throttle + continuous autofire):
    before: deposits up to 3.35e9, every one 3-4 lines after a Mech::Reset;
            4-6 of 7 respawns frozen; post-reset myomers T 7700-12100
    after:  deposits >1e7: ZERO across 7 respawns; frozen: ZERO;
            post-reset myomers T 77-178 (vs degradeT=1000)

THEORIES KILLED ON THE WAY, each by operand data, in order:
  * stale pendingHeat carryover (bounded to 1 frame, +1.2K -- gates agent)
  * slow accumulation during the death window (consumers tick the wreck)
  * conduction from a hot neighbour (roster-wide snapshot: ALL partners 77;
    flow trap: zero e6 flows into the myomers, ever)
  * drag/impulse writers (both trapped: never fired)
  * my own earlier "velocity-driven, players accelerate to top speed" close of
    the ticket -- arithmetically impossible (input ceiling ~6.5e5/frame ~=
    60 deg/s; the observed snap was 1,100-21,000 deg/s) and corrected in
    context/subsystems.md, which carried the wrong paragraph.
  * the localAcceleration zero-fill (+0x1dc) restored along the way is KEPT --
    the binary does it -- but it was NOT the cause; the snapshot is rebuilt
    from the position difference one frame later.

Probes kept (all BT_HEAT_LOG-gated): roster-wide [myofreeze] at-death/at-reset/
post-reset (T + heatEnergy + pendingHeat per subsystem), the [heatflow]
conduction trap with full operands, the [myodep] deposit trap with mech
identity + acceleration components.  Engine MOVER.cpp traps reverted -- they
proved their negative (drag/impulse innocent) and do not belong in engine
source.

Gotcha #30 records the class: when the binary's Reset writes a cell you don't
recognize, that write IS the spec -- transcribe the whole zero/seed list; any
prev-value cell backing a finite difference must be re-seeded at every
teleport; and derived state (T) sampled at the reset proves nothing about the
backing producers.

The operator called the shape of this two days ago: "maybe the math gets screwy
in respawning while some systems are ticking while values are being reset."
That is precisely what it was.

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

context/subsystems.md

@@ -319,10 +319,19 @@ heat-per-SECOND at any frame rate.  A literal transcription would add the full t
 frame, so at 170 fps it would inject ~6× the heat the pod ever did.  `BT_MYO_HZ` overrides the
 reference rate for bracketing.
 
-**Consequence for #137:** the heat model is not miscalibrated.  Myomers running away past
-`failT=2000` at sustained top speed is the authentic governor — heat is **quadratic in speed**
-(`work = m·v²·0.5`), so v≈50 on open ground after a respawn is ~9× the input of v≈10-18 in a
-fight.  It is self-limiting: effectiveness hits 0, the mech stops, speed falls, it cools.  What
-players read as "respawned with the heat bar maxed" is that acceleration to top speed, not a
-failed reset ([[combat-damage]] · the reset itself is verified: `T == startingTemperature` at
-every reset).  Whether the cliff is too punishing is a DESIGN call, not a fidelity defect.
+**Consequence for #137 — CORRECTED 2026-08-09, the paragraph that stood here was wrong.** The
+"players read 'respawned with heat maxed' as acceleration to top speed" claim did not survive
+the data: the deposits were e9-scale within 30 frames of the reset, physically impossible from
+motion input (~6.5e5/frame ceiling).  The actual cause was a **dropped binary re-seed**: the
+binary Reset's second instruction (`FUN_00408440(mech+0x58c, origin)`) re-seeds the
+previous-position memory of the AccelerationLastFrame ring feed (+0x81c..+0x82c); the port
+reconstructed the ring but not the re-seed, so the first post-respawn sample computed
+TELEPORT-DISTANCE/dt (~1e5) into the velocity ring, the ring-mean derivative spiked
+`AccelerationLastFrame`, and `termAccel = (1-accEff)·|v|·|a|·m·dt` deposited ~3e9 into
+`pendingHeat` in one tick → myomers snapped from 77 to ~9000 (failT 2000) → speedEffect 0 →
+frozen until cooled.  Fixed by restoring the re-seed (`accelPrevPos = origin.linearPosition` in
+Mech::Reset).  The ~8% field rate was the |v| factor: only pilots whose throttle was still
+forward at the respawn (physical lever / HOTAS — exactly who reported it) had gait-republished
+speed in the spike frames.  The calibration facts above (constants byte-exact, dt-normalised
+kinetic term) all STAND; the in-life governor (running hot at sustained top speed derates the
+myomers) is authentic and remains.