context: correct 0xBD3 — it's the damage/explosion hub (0x434), NOT the valve/Myomers gate

Risk-4 investigation (before wiring WAVE 8) found my earlier 'keystone unblocks 4 things'
claim was wrong. Verified from the binary:
- 0xBD3 SubsystemMessageManager = a damage/explosion consolidation hub (ConsolidateAndSendDamage,
  weaponExplosions), cached to Mech[0x10d]=0x434, mislabeled 'controlsMapper' in our recon (the
  live drive squats there; the real mapper is roster slot 0 via SetMappingSubsystem).
- The valve MoveValve guard (FUN_004ac9c8 ->owner+0x190+0x274) AND the Myomers gate
  (FUN_004ad7d4 ->owner+0x190+0x260) read a DIFFERENT object at mech+0x190 (!= 0x434). So 0xBD3
  does NOT gate the valve/Myomers/MessageBoard; mech+0x190 (unidentified, no decompiled writer yet)
  is the real keystone for those gauge-adjacent routes.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

context/decomp-reference.md

@@ -88,7 +88,8 @@ valid for reading the decomp, NOT for our compiled layout (see [[reconstruction-
 |---|---|---|
 | +0x11c / +0x120 | `damageZoneCount` / `damageZones[]` | inherited Entity; Mech ctor populates the array |
 | +0x124 / +0x128 | `subsystemCount` / `subsystemArray[]` | the [[subsystem-roster]] (NOT the segment table) |
-| +0x190 | `messageManager` | the 0xBD3 SubsystemMessageManager (damage guard / valve+message route source) |
+| +0x190 | gate object (UNIDENTIFIED) | a per-mech status/damage-state object; the valve guard (`FUN_004ac9c8 →+0x274`) + Myomers gate (`FUN_004ad7d4 →+0x260`) deref `owner+0x190`. NOT the messmgr (which is at 0x434). No decompiled writer found yet — see [[open-questions]]. |
+| +0x434 (word 0x10d) | `SubsystemMessageManager` cache | the 0xBD3 damage/explosion hub (factory @10142). Our recon MISLABELS this `controlsMapper` + the drive squats here; the real mapper is roster slot 0. |
 | +0x260 / +0x26c | `localOrigin` = { Point3D linearPosition; Quaternion angularPosition } | ORIGIN.h:15; position@+0x100 in some subsystem views |
 | +0x300 | segment table | skeleton `EntitySegment`s (muzzle sites, joints) |
 | +0x37c | target world `Point3D` | aim source |

context/open-questions.md

@@ -22,10 +22,26 @@ authentic path scoped.
   Win10+wrapper pod config. Status: OPEN.
 
 ## Deferred subsystems / feeds (authentic path scoped, marked in code)
-- **0xBD3 SubsystemMessageManager (WAVE 8)** — the per-mech message/damage hub @mech+0x190. Gates:
-  the condenser valve CONTROL route (`MoveValve` @0x4ae464 is reconstructed but dormant — no
-  caller + its guard reads the messmgr); the MessageBoard source; the Myomers advanced-damage
-  gate; gauge control-mode cycling. What resolves it: reconstruct 0xBD3 + wire the message routes.
+- **0xBD3 SubsystemMessageManager (WAVE 8)** — a per-mech **damage/explosion consolidation hub**
+  (`ConsolidateAndSendDamage` Performance @0049b784, `weaponExplosions` queue, `CommonDamageInformation`;
+  messmgr.hpp). ctor `FUN_0049bca4` (vtable 0x50b954, installs a Performance → ticks). The factory
+  caches it to **`Mech[0x10d]` = byte 0x434**. What wiring it needs: an untangle — our reconstruction
+  MISLABELED `Mech[0x10d]` as `controlsMapper` and `mech4`'s live drive reads it as the mapper, so the
+  real messmgr can't land there until the drive is re-pointed to the true mapper (**roster slot 0**,
+  installed by `SetMappingSubsystem`/`MakeViewpointEntity`; a `MechRIOMapper`). Payoff = authentic
+  damage/explosion consolidation (a COMBAT-fidelity improvement) + fixing the mapper/messmgr conflation.
+  ⚠ **CORRECTION (verified 2026-07):** 0xBD3 does NOT gate the valve/Myomers/MessageBoard — those read a
+  DIFFERENT object at **`mech+0x190`** (both `FUN_004ac9c8` the valve guard `→+0x274` and `FUN_004ad7d4`
+  the Myomers gate `→+0x260` deref `owner+0x190`, which ≠ the 0x434 messmgr cache). The earlier
+  "0xBD3 gates 4 things" note was wrong.
+- **⭐ `mech+0x190` gate object (UNIDENTIFIED — the REAL keystone for the gauge-adjacent routes)** — a
+  per-mech status/damage-state object read by the valve `MoveValve` guard (`owner+0x190→+0x274`) AND the
+  Myomers `OwnerAdvancedDamage` gate (`owner+0x190→+0x260`). No decompiled writer found for `mech+0x190`
+  yet (likely a base-ctor registration or an offset not yet traced). Identifying + reconstructing it is
+  what actually unblocks the condenser valve CONTROL route, the Myomers advanced-damage coupling, and
+  (via its message queue) plausibly the MessageBoard/control-mode routes. What resolves it: trace the
+  `mech+0x190` writer (grep other parts / disas the mech ctor + base ctors) → identify the class →
+  reconstruct + wire.
 - **StatusMessagePool (NULL stub, btstubs.cpp:62)** — the per-player status-message queue.
   BTPlayer+0x1dc is never populated → MessageBoard is empty (authentic for bring-up). What
   resolves it: wire the pool + decode `AddStatusMessage @0042e580` + the `Player__StatusMessage`