#146 respawn: release the DESKTOP throttle -- and close #137, which was never a bug

#137 ("respawn came back with MYOMERS heat MAXED", Oracle; "overheating
generator D", Sauron) sent us through a full two-sided audit of Mech::Reset
and the whole RTIS chain.  Both sides were correct.  The answer was in the
field log all along, one line after the reset:

    [respawn] Mech::Reset 3:30 healed+moved to (...) alive=1
    [techstat] ... every live condition CLEARED
    [techstat] Myomers condition 3 SET        <- Overheating, immediately
    [mppr] in thr=1 -> ...
    [gaitSM] cycleSpeed=14.6 state=12         <- already RUNNING
    [techstat] Condenser5 condition 3 SET     <- "dumping into coolant loop 5"
    [techstat] GeneratorD condition 3 SET     <- Sauron's generator D

The mech respawns STILL UNDER POWER and earns the heat honestly.  Two facts
close it:

1. condition 3 is an OPERATING flag, not an alarm.  Census over one match:
   LLaser_2 33 SET / 33 CLEARED, LLaser_1 31/31, SRM4 26/26, PPC_2 18/18 --
   every volley trips it and clears it.  EVERY subsystem is balanced
   (GeneratorD 5/4, Myomers 5/4, Condenser5 1/1; the extra SET is only the
   log ending mid-heat).  cond 6 BadPower behaves the same (Myomers 8/8).
   Nothing latches.  A post-respawn SET is not evidence of anything.

2. Mech::Reset's subsystem loop starts at index 2 and the ControlsMapper is
   index 0, so the throttle is never reset -- and the BINARY does the same.
   That is right for a pod: the throttle is a PHYSICAL lever still under the
   pilot's hand.  Respawning under power is authentic and stays.

Oracle's read that the myomer heat rate "felt right" was correct.

WHAT IS a real defect (#146), desktop only: the glass bridge merely EMULATES
that lever, with the static ramp accumulator sLever (mech4.cpp:3250) zeroed
ONLY by the X all-stop and a direction-crossing snap.  A pad/keyboard pilot
is physically holding nothing and cannot see the lever, so they respawned at
speed for no reason they could perceive -- and ate the heat load above.  The
Thrustmaster/RIO path was never affected: InterpretControls (@004d2150)
rebuilds throttlePosition every frame from the databound throttleForward.

Fix: queue the existing all-stop at Mech::Reset, reusing the proven path
(it already clears the zero-crossing detent too).  LOCAL VIEWPOINT MECH ONLY
-- gBTDrive is the local bridge's state and Reset also runs for replicants,
so an ungated write would all-stop the player whenever a REMOTE mech
respawned.  Pod-safe besides: with a RIO present the key bridge is off and
gBTDrive.throttle is never read.  BT_NO_RESPAWN_THROTTLE_RELEASE=1 reverts.

Benched 2-node (scratchpad/night13/throttlerespawn.sh): the release fires
1:1 with local respawns on both nodes independently (A 2/2, B 1/1) and never
spuriously.  HONEST LIMIT: the viewpoint gate was NOT stressed -- B ran
Mech::Reset 0 times for A's mech, so the remote-respawn path never fired.
The gate is correct by construction (the isPlayerMech idiom), not proven.
BT_AUTODRIVE cannot test the lever itself (forced mode reads forcedThrottle,
never sLever), and the zeroing path is the X button, proven in the field.

Also keeps BTReportHeatAtReset (heat.cpp, BT_HEAT_LOG): the [heat-t] census
runs on a 5s timer, far too coarse to sample AT the reset.  It is what
proved every roster subsystem including all six Condensers sits at T=77
start=77, and it corrected an earlier false negative from filtering on
IsDerivedFrom(HeatSink).

KB: context/decomp-reference.md gains the routine/self-clearing condition
semantics + this post-mortem, so it is not re-chased; cross-ref in
context/gauges-hud.md.

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

context/decomp-reference.md

@@ -430,6 +430,31 @@ From the weapon `.SUB` records + the charge-curve `.data` constants (PE-parsed a
   recomputes output via `(1 − damage) × rated` and zeroes it. stateAlarm 4's
   producer = the THERMAL BREAKER in GeneratorSimulation itself; a 2026-08-03
   destruction→state-4 bridge was removed as unfounded.
+- **THE CONDITION FLAGS ARE ROUTINE, NOT ALARMS — field-verified 2026-08-08 [T2]:** a
+  `[techstat] <sub> condition <n> SET` is an *operating* flag ("this component is above
+  nominal / browned out RIGHT NOW"), not a fault report. Census over a full Steam match
+  (`steam_20260806_c_michael_XIAOLONG.log`): cond 3 **Overheating** fires 33× on LLaser_2,
+  31× LLaser_1, 26× SRM4, 18× PPC_2 — every weapon trips it on each volley and clears it on
+  cooldown; cond 6 **BadPower** fires 8× on Myomers, 3× each on SLaser_1/PPC_1/MLaser_1 as
+  the bus browns out under simultaneous draw. **Every subsystem's SET/CLEARED counts are
+  balanced** (GeneratorD 5/4, GeneratorA 8/7, Myomers 5/4, Condenser5 1/1 — the odd extra SET
+  is only the log ending mid-heat). Nothing latches. **Never read a post-respawn `condition 3
+  SET` as a reset failure** — that inference cost a full two-sided reset audit (#137 below).
+  Diagnose a heat complaint from the SET/CLEARED *balance* and the throttle state, not from
+  the presence of a SET.
+- **#137 "respawn came back with MYOMERS heat MAXED" = NOT A BUG, closed 2026-08-08 [T2]:**
+  `Mech::Reset` is clean on both sides — bench: every roster subsystem incl. all six
+  Condensers at `T=77 start=77`; field log: every live condition CLEARs 12–16 lines after each
+  reset. The heat is real and immediate because **the mech respawns still under power**: at the
+  reset the log reads `thr=1`, `cycleSpeed=14.6`, gait state 12 (running), and the myomers →
+  Condenser5 → GeneratorD trip Overheating within ~1–2 s. `Mech::Reset`'s subsystem loop starts
+  at **index 2** and the ControlsMapper is **index 0**, so the throttle is never reset — and the
+  binary does the same, which is correct for a pod whose throttle is a PHYSICAL lever still
+  under the pilot's hand. **Desktop caveat (real, and separate):** the glass bridge emulates
+  that lever with a file-static ramp accumulator `sLever` (mech4.cpp:3250), zeroed ONLY by the
+  X all-stop and a direction-crossing snap — so a pad/keyboard pilot, who is physically holding
+  nothing, likewise respawns at speed with the lever state invisible. Port-layer question, not
+  a heat bug.
 - **DEATH SCORE COST decoded 2026-08-02 (#118 tail) [T1]:** the death handler tail
   `@004c07cd-0x4c0828` (inside the @004c05c4 export gap — missing from the #52
   reconstruction) gates on `advancedDamageOn`(+0x264) and hands the ENGINE base