#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

game/reconstructed/myomers.cpp

@@ -809,6 +809,31 @@ void Myomers::MyomersDriveHeat(Scalar time_slice)
 	Scalar termAccel   = velComplement  * velMag * accMag * mass * time_slice;
 	Scalar gain        = ratio * ratio * damageGain;
 
+	// #137 DEPOSIT TRAP (BT_HEAT_LOG): conduction into the myomers is measured
+	// ZERO post-respawn (the [heatflow] trap), weapons deposit into themselves,
+	// so THIS add is the only writer left that can carry the observed one-shot
+	// slug (9e7..2.3e9, varying per respawn).  The [myoheat] receipt is
+	// time-sampled and would miss a 1-2 frame spike; this prints EVERY add
+	// over 1e6 with the full operand set, unconditionally.
+	{
+		Scalar deposit = gain * (termClimb + termKinetic + termAccel);
+		if (getenv("BT_HEAT_LOG") != 0 && (deposit > 1.0e6f || deposit < -1.0e6f))
+		{
+			// WHOSE mech (master vs the peer's replicant shares this log!) and
+			// the acceleration COMPONENTS (pure-y = gravity accumulation on the
+			// wreck; planar = teleport/warp-derived).
+			Mech *om = (Mech *)owner;
+			const Vector3D &av = om->localAcceleration.linearMotion;
+			DEBUG_STREAM << "[myodep] mech=" << om->GetEntityID()
+				<< (om->GetInstance() == Entity::ReplicantInstance ? " REPL" : " mstr")
+				<< " deposit=" << deposit
+				<< " v=" << velMag << " a=" << accMag
+				<< " aXYZ=(" << av.x << "," << av.y << "," << av.z << ")"
+				<< " vy=" << vy << " dt=" << time_slice << " gain=" << gain
+				<< " climb=" << termClimb << " kinetic=" << termKinetic
+				<< " accel=" << termAccel << "\n" << std::flush;
+		}
+	}
 	pendingHeat /* @0x1C8 */ += gain * (termClimb + termKinetic + termAccel);
 
 	if (getenv("BT_MYO_LOG"))