Issue #22: respawn resets ammo + repairs weapons (the +0x28 mislabel)

ROOT CAUSE [T1]: Mech::Reset's subsystem sweep (@0049fb74 loop-2) calls
vtable slot +0x28, which the DATA-section vtables prove is
ResetToInitialState (0050f9d8/00511d2c/00512078/0051242c all carry the
class RTIS at +0x28) -- our reconstruction mislabeled it DeathReset,
the EMPTY engine base virtual, so the whole per-subsystem reset was a
silent no-op ("ammo and weapons do not reset on respawn", playtest
night; matchlogs: 3 of 7 players fired zero projectiles after their
first death).

SECOND LAYER: the binary never refilled ammo at all -- its respawn
severed the vehicle and DropZoneReply built a NEW mech (fresh ctor =
full bins, pristine subsystems: the pod behavior testers remember).
Our port deliberately reuses the entity (the new-mech path was the
two-mech/camera-glitch family), so Reset now EMULATES ctor-freshness:

- the sweep starts at i=2 (binary-faithful: skips mapper + voltage
  bus) and dispatches the engine DeathReset virtual as the vehicle;
  per-class overrides chain each class's own authentic slot-10 RTIS
  body (the recon RTIS namesakes are statically bound -- no common
  virtual): MechWeapon @004b96ec, Emitter @004ba4d0 (charge cycle
  restarts from Loading), ProjectileWeapon @004bbaf8 (unjams).
- MechSubsystem::RespawnRepair (PORT): heals the subsystem's PRIVATE
  crit damage zone + status alarm -- the mech-zone heal never touched
  those, which kept destroyed weapons dead across respawns.
- AmmoBin::DeathReset (PORT): refills to initialAmmoCount (@0x220, the
  ctor value) + Loaded alarm + idle feed + cook-off disarmed;
  ResetToInitialState stays authentically EMPTY per AMMOBIN.TCP.

Verified (2-node force-damage kill/respawn rig, BT_DEATH_LOG): every
respawn logs [respawn] ammo bin refills for both bins to streamed
capacity across 4 death cycles; mission un-regressed.  KB corrected +
swept (multiplayer.md task #52 notes).  Awaiting live tester
verification of depleted-bin refill + revived weapons.

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

context/multiplayer.md

@@ -675,8 +675,17 @@ transition, HUD all landed since P6): console egg → mesh → RunningMission on
    SimulationState dial, independent of that sim path.
    Mech::Reset (@0049fb74) does the full subsystem-reset sweep (mech4.cpp:1616 loops every subsystem →
    `DeathReset(mode)`, restoring heat/power/ammo/charge) + heals all damage zones + ForceUpdate(0x1f).
-   (Per-subsystem `DeathReset` bodies are authentically trivial/empty for some classes — the shipped
-   build folds those overrides — so "fuller" reset behavior is per-subsystem, not a missing sweep.)
+   **⚠ CORRECTED (2026-07-23, issue #22): the loop-2 slot vtable+0x28 is `ResetToInitialState`,
+   NOT DeathReset** [T1: the DATA-section vtables 0050f9d8/00511d2c/00512078/0051242c all carry the
+   class RTIS at +0x28] — the old mislabel made the port sweep the EMPTY engine DeathReset virtual
+   (a no-op) = the field bug "ammo/weapons don't reset on respawn."  Also: the binary loop starts
+   at **i=2** (skips mapper + voltage bus).  And the binary's respawn severed the vehicle and built
+   a NEW mech (fresh ctor = full ammo/pristine subsystems — the pod behavior); our entity-reuse
+   respawn therefore adds FRESH-MECH EMULATION: per-class `DeathReset` overrides chain each class's
+   own authentic RTIS body (the recon RTIS namesakes are statically bound — no common virtual), and
+   `MechSubsystem::RespawnRepair` + `AmmoBin::DeathReset` restore the private crit zones / status
+   alarms / ammo (`initialAmmoCount` @0x220) the mech-zone heal never touched.  See mech4.cpp
+   Mech::Reset + ammobin.cpp.
    **Three respawn bugs found + fixed on the way (all [T2], 2-node force-damage verified):**
    (i) **death-latch un-latch** — `IsMechDestroyed` tested `graphicAlarm>=9` alone; a later leg hit
    on the wreck rewrites the alarm to 4/3, un-latching → the death transition RE-RAN (double kill,