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>

game/reconstructed/mech4.cpp

@@ -1757,14 +1757,32 @@ void
 			zone->Heal();
 	}
 
-	// --- RESET every subsystem (the decomp's loop-2 vtable+0x28 = DeathReset,
-	//     the base virtual symmetric with the DeathShutdown we run on death):
-	//     restores each subsystem's heat/power/ammo/charge to the initial state ---
-	for (int i = 0; i < GetSubsystemCount(); ++i)
+	// --- RESET every subsystem (issue #22 correction, 2026-07-23).  The
+	//     binary loop (@0049fb74 loop-2) runs i=2..count (skipping the mapper
+	//     + voltage bus) calling vtable+0x28 -- which the DATA-section vtables
+	//     prove is ResetToInitialState [T1: 0050f9d8/00511d2c/00512078/0051242c
+	//     all carry the class RTIS at +0x28], NOT DeathReset (the old comment's
+	//     mislabel: DeathReset is the ENGINE base virtual, empty everywhere,
+	//     so the whole sweep was a no-op = "ammo/weapons don't reset on
+	//     respawn").  The recon classes' RTIS bodies are statically-bound
+	//     namesakes (no common virtual), so the engine DeathReset virtual is
+	//     the DISPATCH VEHICLE: each class's DeathReset override chains its
+	//     own authentic RTIS body (+ the fresh-mech extras below).
+	//
+	//     FRESH-MECH EMULATION [PORT divergence, documented]: the binary
+	//     respawn severed the vehicle and built a NEW mech (fresh ctor = full
+	//     ammo, pristine subsystems -- the pod behavior testers remember);
+	//     our port REUSES the entity (the new-mech path was the two-mech/
+	//     camera-glitch family), so Reset must also repair each subsystem's
+	//     PRIVATE crit damage zone + status alarm -- the mech-zone heal above
+	//     never touches those, which kept destroyed weapons dead forever.
+	for (int i = 2; i < GetSubsystemCount(); ++i)		// binary: i = 2 start
 	{
 		Subsystem *s = GetSubsystem(i);
-		if (s != 0)
-			s->DeathReset(mode);
+		if (s == 0)
+			continue;
+		s->DeathReset(mode);						// -> per-class RTIS chain
+		((MechSubsystem *)s)->RespawnRepair();		// fresh-mech: zone + status
 	}
 
 	// --- locomotion pre-run + interest gates (a reset master must tick) ---