projweap: correct the msg-2 jam claim (it CAUSES jams, decomp-verified)

HandleMessage @004bcabc: message 2 -> SetLevel(weaponAlarm, 5) -- a
malfunction INDUCER, not an unjam; the state-machine comment had it
backwards.  There is NO in-mission unjam in the binary (jams clear only
at ResetToInitialState = mission reset/respawn), and the EJECT cycle is
the anti-cook-off ammo jettison (DumpAmmo -> NoAmmo), not an unjam.
The old 'unjam delay' follow-up suggestion is retired as unauthentic.

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

game/reconstructed/projweap.cpp

@@ -551,8 +551,8 @@ Logical
 	// so gate the roll on the weapon actually being in a degraded HEAT STATE (heatAlarm
 	// level >= 1) instead of the raw heatLoad.  In bring-up the alarm stays 0 (temp <<
 	// degradation threshold) -> weapons fire reliably; real jams return once the heat model
-	// drives true temps.  (FOLLOW-UP: make JammedState recoverable via an unjam delay so
-	// even a genuine overheat jam clears.)
+	// drives true temps.  (The old FOLLOW-UP suggesting an "unjam delay" is RETIRED --
+	// 2026-07-23 decomp check: the binary has NO in-mission unjam; permanence is authentic.)
 	if (heatAlarm.GetLevel() < HeatSink::DegradationHeat)		// was: if (heatLoad <= 0.0f)
 		return False;
 
@@ -776,7 +776,13 @@ void
 															// -- the recharge dial ANIMATES
 		break;
 
-	case 5:		// Jammed @4bbe8e -- cleared only by ResetToInitialState / msg 2
+	case 5:		// Jammed @4bbe8e -- cleared ONLY by ResetToInitialState (mission
+				// reset/respawn).  ⚠ CORRECTED 2026-07-23: msg 2 CAUSES a jam
+				// (HandleMessage @004bcabc: SetLevel(this+0x350, 5) -- a
+				// malfunction inducer), it does NOT clear one; the old comment
+				// had it backwards.  There is NO in-mission unjam in the
+				// binary -- the EJECT cycle (UpdateEject) is the anti-cook-off
+				// ammo JETTISON (DumpAmmo -> NoAmmo), not an unjam.
 		if (trigger)
 		{
 			weaponAlarm.SetLevel(TriggerDuringJamState);	// @4bbe95 blip 6