Fix 2 (Gitea #12): gauge tree survives the in-session mech re-stream

The pre-launch host drop/rejoin re-stream re-creates every mech at mission
launch; the LOBBY-built gauge tree kept attribute pointers into the freed
first-stream mechs, every widget Execute AV'd, and the BT_DEV_GAUGES SEH
guard (Gauge::GuardedExecute, GAUGE.cpp:618) disabled each one PERMANENTLY
(rate=0, no rebind) -- the frozen dev-gauges window of incident #12.  The
authentic engine flow only tears the tree down at mission transitions
(Application::Shutdown -> gaugeRenderer->Shutdown() -> ShutdownImplementation
-> Remove(0), APP.cpp:787 / GAUGREND.cpp:3264); the re-stream bypassed it.

Fix: BTL4GaugeRenderer::TearDownForViewpointRestream() performs the
ENTITY-BOUND half of that same ShutdownImplementation sequence, in order
(gaugeAlarmManager->RemoveAllAlarms() -> Remove(0) -> moving/static entity
grid Clear), keeping the mission-scoped state (warehouse, graphics ports,
interpreter, controls-owned L4Lamps -- RemoveAllLamps would delete them
behind the buttonGroup's &lamp->automaticValue registrations).  Called from
BTL4Application::MakeViewpointEntity before ConfigureForModel("Init") on any
viewpoint RE-make -- that handler runs once per stream (the incident log's
[ctrlmap] installing x2) -- so the tree rebuilds bound to the NEW mech via
the renderer's existing lazy build.  Sentinel: "[gauge] viewpoint re-stream:
tearing the gauge tree down for rebuild".

Verified with the 2-instance relay harness (port 15600, MP_RELAY.EGG,
the incident sequence): join A (dev gauges) + B, kill B by exact PID at
WAITING FOR OPERATOR LAUNCH, rejoin B, operator launch.  Pod A re-streamed
(2x ctrlmap install, 4x zonebuild), logged the sentinel, and post-launch the
docked composite is fully live (mission clock/heading/radar advancing between
BT_SHOT frames) with ZERO [gauge-fault] DISABLED lines (the incident had 11).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

context/gauges-hud.md

@@ -92,8 +92,19 @@ PERMANENTLY, nothing re-enables or rebinds → the whole window static for the r
 session (= symptoms 1+3).  The AUTHENTIC engine flow handles mission transitions by
 `Application::Shutdown → gaugeRenderer->Shutdown() → ShutdownImplementation → Remove(0)` (all
 gauges deleted, tree lazily rebuilt next mission, APP.cpp:787/GAUGREND.cpp:3264) — the port's
-in-session re-stream path bypasses it.  OPEN: rebuild/rebind the gauge tree on a viewpoint-mech
-re-stream (or route the rejoin through the engine Shutdown flow); see [[open-questions]].
+in-session re-stream path bypasses it.  **FIX LANDED (2026-07-19, awaiting human MP verify):**
+`BTL4GaugeRenderer::TearDownForViewpointRestream()` (btl4grnd.cpp) performs the ENTITY-BOUND
+half of the engine ShutdownImplementation sequence, same order (RemoveAllAlarms → Remove(0) →
+entity-grid Clear), deliberately KEEPING warehouse/graphics-ports/interpreter/controls-L4Lamps
+(RemoveAllLamps mid-session would delete the CONTROLS-owned L4Lamps behind the buttonGroup's
+`&lamp->automaticValue` registrations — a dangling mapping; the mech-state "lamps" like
+AnimatedSubsystemLamp are Gauges and go with Remove(0)).  Called from
+`BTL4Application::MakeViewpointEntity` before `ConfigureForModel("Init", entity)` whenever the
+viewpoint is a RE-make (that handler empirically runs once per stream — twice in the incident
+log, `[ctrlmap] installing` ×2) — the tree then rebuilds bound to the NEW mech.  Log sentinel:
+`[gauge] viewpoint re-stream: tearing the gauge tree down for rebuild`.  Residual exposure:
+`Remove(0)` flushes each gauge (`Update(gaugeRate_A)`, GAUGREND.cpp:3465) before deleting it, so
+gauge CONNECTIONS may read the freed mech once more (plain reads; Execute stays SEH-guarded).
 
 ## The secondary screen's THREE views (Damage / Critical / Heat) — mode-gated [T0/T1/T2]
 The `sec` port stacks three mode-gated mech-schematic layers at offset (50,0) over the

context/open-questions.md

@@ -629,29 +629,33 @@ register.  ⚠ The audit also flags the damage-economy item as SELF-CONTRADICTOR
   numbers no longer point at that code).
 
 ## Multiplayer (Phase 7 / P6)
-- **Gitea #12 MP incident (2026-07-19) — root causes found, FIXES NOT YET LANDED (blocked on a
-  live-verify window; the user was playing).** Findings [T1/T2 — see the #12 comments +
-  `scratchpad/incident_2157/`]:
+- **Gitea #12 MP incident (2026-07-19) — root causes found; BOTH FIXES LANDED 2026-07-19
+  (awaiting the human MP death-and-survive verification).** Findings [T1/T2 — see the #12
+  comments + `scratchpad/incident_2157/`]:
   (1) *Gauge-window freeze* = lobby-built gauge tree dangling over a mission-launch mech
   RE-STREAM after a pre-launch host drop/rejoin; SEH guard disables each faulted gauge
-  permanently — see [[gauges-hud]] §MP gauge-window FREEZE.  FIX TODO: rebuild/rebind the gauge
-  tree on a viewpoint re-stream (engine analog: `Application::Shutdown` →
-  `gaugeRenderer->Shutdown()`); also consider re-enabling (not just disabling) a faulted gauge
-  after a rebind.
-  (2) *Missiles cycle-but-never-launch*: the port's ProjectileWeaponSimulation is a RivetGun
-  approximation — the AUTHENTIC @004bbd04 machine is now fully recovered ([[decomp-reference]]
-  §5).  Port defects to fix faithfully: fault gate reads `simulationFlags==1` (binary:
-  `simulationState@0x40==1`); `simulationFlags|=0x1` on every salvo/beam = engine
-  DelayWatchersFlag poisoning ([[reconstruction-gotchas]] §20; binary = `updateModel|=1` ==
-  ForceUpdate); view/target gating + ConsumeRound live in the port's FireWeapon (binary: in the
-  caller, with a 4-blip stay-Loaded denial — the port instead fakes a full Firing→Loading pip
-  cycle on a denied shot, which is exactly the reported symptom); recoil never clamped at 0
-  (runs to −114); slot-17 @004b9c9c (rechargeLevel) never called.  Solo repro on 4.11.387
-  (pre-stop-order): SRM6s latch alarm 7 PERMANENTLY mid-session after a heat-failure episode
-  (recoil pinned → released → state 7 forever) — missiles stop while lasers keep working, with
-  or WITHOUT J/K/L presses.  The binary's state 7 is also permanent once entered [T1] — open
-  fidelity question: is launcher FailureHeat reachable at authentic heat economy, or does our
-  launcher self-heat run hot? (Emitters never trip it — task #11 duty-cycle measurement.)
+  permanently — see [[gauges-hud]] §MP gauge-window FREEZE.  ✅ FIX LANDED:
+  `BTL4GaugeRenderer::TearDownForViewpointRestream()` (alarms + Remove(0) + entity grids — the
+  entity-bound half of the engine `ShutdownImplementation`), called from
+  `MakeViewpointEntity` before `ConfigureForModel` on a viewpoint RE-make; the tree rebuilds
+  bound to the new mech.  Sentinel: `[gauge] viewpoint re-stream: tearing the gauge tree down`.
+  (2) *Missiles cycle-but-never-launch*: ✅ FIX LANDED — the port's RivetGun-approximation
+  ProjectileWeaponSimulation replaced with the disasm-exact @004bbd04 machine
+  ([[decomp-reference]] §5; projweap.cpp): fault gate reads `simulationState@0x40==1`; the
+  `simulationFlags|=0x1` DelayWatchersFlag poisoning removed everywhere
+  ([[reconstruction-gotchas]] §20 — emitter SetDirty split into ForceUpdate/ExecuteOnUpdate per
+  site); view/target gating + the `bin->FeedAmmo` pull + recoil set moved into the caller's
+  Loaded case with the authentic 4-blip stay-Loaded denial; recoil bleeds ONLY in Loading at
+  electrical-Ready and clamps at 0; slot-17 @004b9c9c called from Loading/7 (the launcher
+  recharge dial now ANIMATES).  State 7 kept binary-faithful (re-asserted unconditionally —
+  permanent once entered; recovery only via ResetToInitialState/mission reset).  Solo-verified
+  on 4.11.388+: 54-60 `[projectile] PUSH` + impact smoke; denial window (BT_LOOK_TEST
+  look-back) = trig pulses, state STAYS 2, zero launches, resumes on release; disabled-mech
+  gate pins enemy launchers at 7+full recoil; STREAK-6 dial sweeps across screenshots; lasers
+  fire throughout.  Open fidelity question REMAINS: is launcher FailureHeat/jam-rate at
+  sustained autofire authentic-intensity? (both SRM6s jam within ~2 min of held autofire via
+  the bring-up CheckForJam heat gate; emitters never trip it — task #11 duty-cycle
+  measurement.)
   (3) *J/K/L preset hypothesis REFUTED for solo* [T2]: BT_PRESET_TEST cycling on 387 — missiles
   kept launching after presets (36 PUSH before / 24 after), pip count unchanged, gauges live,
   [mode] masks touch ONLY ModeMFD bits 0-14 (`reticleElementMask` is a different object).