#81 ghost: light the SILENT DISCARD -- the only path a respawn can vanish on

Walked the respawn handshake end to end and measured the assumptions.  Two
eliminations and one find:

ELIMINATED: the engine hunt re-posts to itself every 2s forever while the mech
is dead (PLAYER.cpp:325-327; its only state-based exit never fires, see below),
and the DropZone re-grants the SAME slot to a repeat request from the same
requester+deathCount even while busy (DROPZONE.cpp:182-194).  So neither a
transient "no slot" nor a single lost reply can strand a respawn -- the request
keeps being re-sent and re-granted.  A permanent strand needs a permanent cause.

THE FIND: BTPlayer::DropZoneReplyMessageHandler ends
  if (!playerVehicle) ... else if (deathCount == message->deathCount) ... else { return; }
and that last branch was a BARE RETURN WITH NO LOG.  The drop zone grants a
spot, replies, the numbers disagree, the reply is dropped, deathPending stays
latched, the mech is never Reset -> permanent ghost, zero evidence.  That is
why 6 of 8 field cycles stranded silently.  Now always-on, printing the
DIRECTION of the mismatch: msgDeath < ours = genuinely stale (dropping is
right); msgDeath > ours = our counter is behind and we just threw away a LIVE
respawn -> points straight at #45 (the death tally does not replicate).
Deliberately NOT auto-recovered: guessing would be a stand-in, and the wrong
guess resets a mech that is still alive.

LANDMINE DOCUMENTED IN CODE: Set_Alarm_Level is an empty stub (btstubs.cpp:87),
so the death path's Set_Alarm_Level(this+0x2c,1) and the reply's (+0x2c,2) are
no-ops.  Their values decode against Player's enum as DropZoneAcquiredState(1)
and VehicleTranslocatedState(2), which makes "these should obviously be
SetSimulationState() calls" both attractive and CATASTROPHIC: the engine hunt is
gated on GetSimulationState() != DropZoneAcquiredState, so setting 1 on death
would stop AssignDropZone ever being dispatched and ghost EVERY pilot.  Measured
our simulationState at 0x24 (not 0x2c) and the write leaves it 0; in the binary
+0x2c is the Simulation-base alarm (the field the mech side calls graphicAlarm,
@0x4ac126 "owner alarm+0x2C -> level 9"), which our layout models only on Mech.

Verified solo: a healthy death+respawn logs the grant and the RESET and emits
ZERO discard/gate-off lines (no false positives).

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

docs/GHOST_MECH_ANALYSIS.md

@@ -56,6 +56,51 @@ this behaviour is authoritative for what we compile, *not* for what the pods did
 unrecovered gap. Recovering it (byte-scan + windowed disasm, the technique that recovered
 `FUN_004a6344`) is the open task.
 
+## 2026-07-30 dig: the respawn handshake, walked end to end
+Re-read the whole chain (death → +5 s re-post → engine hunt → DropZone grant → reply → Reset) and
+**measured** the parts that were assumptions. Results, in order of importance:
+
+**1. The engine hunt RETRIES EVERY 2 SECONDS, forever, while the mech is dead** [T0]
+(`PLAYER.cpp:325-327` posts the message back to itself unconditionally; its only state-based exit is
+`GetSimulationState() == DropZoneAcquiredState`, which never happens — see 3). The DropZone also has
+a resend net: a repeat request from the same requester + same `deathCount` re-grants the **same**
+slot even while it is busy (`DROPZONE.cpp:182-194`). **So "a transient no-slot" and "one lost reply"
+are both ELIMINATED as causes** — the request keeps being re-sent and re-granted every 2 s. A
+permanent strand needs a permanent reason.
+
+**2. THE SILENT DISCARD — the one remaining unlit path, now instrumented** [T1]
+`BTPlayer::DropZoneReplyMessageHandler` is `if (!playerVehicle) … else if (deathCount ==
+message->deathCount) … else { return; }`. That final branch was a **bare return with no logging**:
+the drop zone granted a spot and replied, the numbers disagreed, and the reply was dropped —
+`deathPending` stays latched, the mech is never `Reset`, and the pilot is a permanent ghost **with
+zero trace in the log**. That is exactly why 6 of 8 field cycles stranded leaving no evidence. Now
+always-on (`[ghost] DROP-ZONE REPLY DISCARDED …`) and it prints the **direction** of the mismatch,
+which decides the fix: `msgDeath < ours` = genuinely stale (dropping is correct); `msgDeath > ours` =
+**our counter is behind and we threw away a live respawn** — which points straight at #45 (the death
+tally does not replicate correctly). Deliberately NOT "recovered" yet: guessing the direction would
+be a stand-in, and the wrong guess respawns a mech that is still alive.
+
+**3. ⚠ LANDMINE — do not convert the two `Set_Alarm_Level` raw writes to `SetSimulationState()`.**
+`Set_Alarm_Level` is an **empty stub** (`btstubs.cpp:87`), so the death path's
+`Set_Alarm_Level(this+0x2c, 1)` and the reply path's `(this+0x2c, 2)` are **no-ops** today. Their
+values decode perfectly against `Player`'s enum (`PLAYER.h:273-279`) as `DropZoneAcquiredState`(1)
+and `VehicleTranslocatedState`(2) — `DropZoneAcquiredState = Entity::StateCount`, and `Entity` adds
+no states, so it is **1**. That makes "obviously these should be `SetSimulationState` calls" a very
+attractive and **catastrophic** fix: the engine hunt is gated on `GetSimulationState() !=
+DropZoneAcquiredState`, so setting state 1 on death would stop `AssignDropZone` from ever being
+dispatched and make **every** pilot ghost permanently.
+Measured: our `BTPlayer::simulationState` is at **0x24**, not 0x2c, and the write leaves it at 0
+(`[ghost] death raw-write(+0x2c,1): simState 0 -> 0 (hunt gate still open)`). In the binary `+0x2c`
+is the **Simulation-base alarm** — the same field the mech side calls `graphicAlarm` (`@0x4ac126`:
+"owner alarm+0x2C -> level 9"). Our layout models that only as a `Mech` member, so a `BTPlayer` has
+nowhere to put it; the stub is harmless until we recover what reads a *Player's* alarm in the binary
+(likely a cockpit/HUD respawn indicator). [T1 offsets, T3 purpose]
+
+**Revised theory of the ghost:** not drop-zone starvation (see below) and not a lost reply (see 1),
+but a **`deathCount` mismatch between the player and the reply**, silently discarding a live
+respawn — MP-specific in a way solo structurally cannot reproduce (solo respawn works every time;
+6 of 8 MP cycles stranded), and directly coupled to the known #45 replication defect.
+
 ## What the instrumentation already killed
 `slots=8` (measured, `[dz] POOL`). An 8-slot pool **cannot** be cooldown-starved by 5 players (at
 most 5 slots on cooldown at once), so the shared `dropzone=one` in `tools/eggmodel.py:42` is **not**