#45 review pass: correct three claims the fix's own comments got wrong

An adversarial review of the change returned NO BLOCKERS but caught three
statements that were wrong or unverifiable.  All three are corrections to my own
comments/docs, not behaviour changes -- the verified binary is unchanged.

1. The phantom-kill note had the ORDERING backwards.  It claimed the owner's
   record "overwrites it on the next record -- the phantom stops being visible".
   The engine's event priorities run the other way: an inbound update record is
   posted at UpdateEventPriority == MaxEventPriority and drained by
   ExecuteBackgroundTask, while the rerouted score message sits at
   EntityManagerEventPriority == DefaultEventPriority and is popped later -- so
   the correction usually lands FIRST and the phantom AFTER it.  The artifact is
   BOUNDED, not masked: on the killer's pod only, that victim's KILLS reads +1
   until the next record, i.e. <= one 2s heartbeat instead of "until the victim
   next scores or dies".  Swept in btplayer.cpp, KD_SCOREBOARD_PLAN.md and
   RECONCILE.md.

2. The corpus figures were not reproducible, and were mis-tiered.  I cited
   "125 of 125 SCORE type=2 over 255 node-logs" and "0 of 8800 DMG rows" -- true
   when measured, but the corpus is append-only and this fix's OWN verification
   runs grew it from ~255 to 425 files, so nobody can re-derive them.  Replaced
   everywhere with invariant RATIOS that hold at any corpus size, re-measured
   here:
     * 0 of 18818 DMG rows are inst=R (damage is applied master-side only)
     * 439 of 439 DEATH inst=R rows read killer=0:0 killdmg=0.000, against
       0 of 225 inst=M rows (sole lastInflictingID writer: mech.cpp:746)
   Also re-tagged T1 -> T2: log-corpus field evidence is T2 per the CLAUDE.md
   tier table.  Lesson recorded in the banner: cite ratios, not counts, for a
   corpus your own rigs append to.

3. The recordLength guard's justification was wrong (and the plan's risk 5 with
   it).  A short legacy record does NOT desync the stream -- both sides advance
   by the WRITER's stamped recordLength and no reader asserts a length.  The real
   hazard is a read PAST THE ALLOCATION: an inbound update message lives in a
   per-event heap block sized from messageLength, so on a TRAILING legacy record
   the two new fields would be read off the end of it.

Plus: the record struct's own field comment still said "deathCount -- the DEATHS
column", the exact wrong-field belief #45 removed, sitting on the wire struct.

Filed the review's other finding on #60: a SECOND decomp export gap, index
jumping FUN_0049fe80 (ends 0x49ffc8) -> FUN_004a1232, 4714 unexported bytes
containing Mech::TakeDamageMessageHandler @0x4a0230 -- the producer of every
score and death message in the game.  Verified independently against
functions_index.tsv before posting.

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

context/gauges-hud.md

@@ -336,14 +336,15 @@ locked**. **SUPERSEDED -- that "RESOLVED" claim was FALSE (corrected 2026-07-25,
 observed-tally design never ran: `BTPlayerCountObservedDeath`'s only call site is
 replicant-gated but sits INSIDE `Mech::UpdateDeathState`'s once-per-death transition, which a
 replicant never enters (it takes the mode-9 early return) -- and it could not have worked
-anyway, because a replicant victim carries no attribution at all (**0 of 8800** `DMG` rows in
-the corpus target a replicant, so every `DEATH inst=R` row reads `killer=0:0`). What actually
+anyway, because a replicant victim carries no attribution at all (**0 of 18818** `DMG` rows in
+the corpus are `inst=R`, which is why **439 of 439** `DEATH inst=R` rows read `killer=0:0`
+against **0 of 225** `inst=M` rows). What actually
 happened: BOTH counters lived only on the OWNING pod, so every REMOTE row read 0/0 all
 mission -- KILLS because `Entity::Dispatch` reroutes a replicant's ScoreMessage to the master
 (ENTITY.cpp:244-251), so `++killCount` lands on the killer's own machine; DEATHS because the
 `VehicleDead(-1)` handler runs on the victim's own master. Neither counter rode an update
-record. Measured: **125 of 125** `SCORE type=2` rows across 255 node-logs credit the LOGGING
-node's own player; not one credits a remote pilot. [T1]
+record. [T2 — stated as ratios above; an earlier draft's "125 of 125 over 255 node-logs" was
+true when measured but is not reproducible, because every rig run appends to the same corpus.]
 **FIXED 2026-07-25 [T2, rig-verified]:** DEATHS now reads the binary's OWN `+0x280` column
 (`BTPlayer::deathTally`, our offset 0x274 -- previously declared `pad_0x280` and "dead"), not
 `Player::deathCount` (which is the respawn-handshake identity, seeded -2 -- exactly what the