Twenty launches say the fried-pod fix holds

Verification run for f86b604: four pods, full page heap throughout, the
fixed binary confirmed by hash in the first line of the log. Twenty valid
samples - every one of them four pods on the podium and a full teardown -
and no fault.

Before the fix the rig trapped twice in eleven instrumented launches, about
one in five. Twenty clean at that rate is roughly a one-in-fifty
coincidence, which is as much as twenty launches can say and enough to call
it held.

What this does NOT settle is the crash the rig was built for. The original
playtest dumps are a double-delete in ~JointedMover under
Application::Shutdown, and that stack has not appeared once in thirty-odd
instrumented launches. The bug that was caught and fixed is a real
use-after-free on the same path - a Player following a vehicle that had been
fried - and it may well be the same root, since a VTV freed while others
still hold it would be deleted again at Shutdown. But nothing here
demonstrates that, and the rig stays.

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

tools/podium-repro/README.md

@@ -223,6 +223,29 @@ exits, no exception. Then the cdb logs turned out to carry no
 weaker even than the earlier light-page-heap ones. Its only value is as one
 more sample of the crash failing to happen on its own.
 
+**2026-08-14 — THE RIG CAUGHT ONE, AND THE FIX HOLDS.** `loop.ps1`, four
+pods, full page heap. Launch 9 of the first batch trapped:
+
+    ExceptionAddress: rpl4opt!Quaternion::operator=
+      [inlined in Player::GoToVehicle+0xe]   reading a FREED block
+    free stack: operator delete <- VTV::`scalar deleting destructor'
+                                <- FryDeathRowTask::Execute
+
+`this` was a live remote `RPPlayer`. Cause: `Player::playerVehicle` is a bare
+pointer nothing ever cleared, and a replicant Player's whole performance is
+`GoToVehicle`, reading it every frame - so from the fry onward it read freed
+memory, normally mapped and full of garbage. Fixed in `f86b604` by clearing
+it in `Entity::CondemnToDeathRow`.
+
+Rate before the fix: 2 traps in 11 instrumented launches, about 1 in 5.
+After: **20 of 20 valid samples, no fault.** At the measured rate that is
+roughly a one-in-fifty coincidence, so the fix holds as well as twenty
+launches can say.
+
+A wasted batch in between is the reason `loop.ps1` now refreshes the pod
+exes: it trapped at the same address on the 09:33 binary while the fix sat
+in the 11:20 one. Check the `exe:` line before reading any result.
+
 **2026-08-14, FOUR pods, FULL page heap (`flags 0x3`), driven, podium ON:
 no crash. This is the first properly instrumented negative.** Everything the
 diagnosis points at ran and survived: `WinnersCircle: 4 placed on 8 spots`,