diff --git a/docs/re/mission-freeze-heap-exhaustion.md b/docs/re/mission-freeze-heap-exhaustion.md
index 6bbbb84..680ff02 100644
--- a/docs/re/mission-freeze-heap-exhaustion.md
+++ b/docs/re/mission-freeze-heap-exhaustion.md
@@ -424,3 +424,31 @@ That leaves the two paths clearly separated:
 
 The flag is cheap and silent, so it has been **left enabled** in the container's
 `xenia-canary.config.toml`.
+
+## 🔴 Not a regression — an older binary reproduces it exactly
+
+The obvious suspicion was that recent canary work broke it: this corpus has a
+**500-second** Stage 02 flight from **2026-08-10**, and the tree gained the
+file-pad driver, the UI-draw capture, a `threading_posix` resume fix and
+`log_stuck_waits` between then and now, with the running binary rebuilt on
+**08-24**.
+
+The container keeps older builds (`/sylph-home/re/bin/*/xenia_canary`, and a
+host build from **08-17** predating all of the 08-19 changes), and `run-canary`
+takes `$XENIA_BIN` — so this needed no rebuild. Running the **08-17** binary
+through the same route to the same point:
+
+    alloc failures: 1    guest throws: 1
+
+**Identical.** So the failure is not new, and bisecting the emulator is not the
+way in. ⚠️ That also means the 08-10 run, which flew for 500 s, did *not* differ
+by binary — whatever let it reach flight is in the **route or the game state**,
+not the build.
+
+❔ That is the open question now, and it is sharper than "why does it freeze":
+**what did the working runs hold in memory that these do not?** Both of the two
+largest live blocks — 112.88 MB at `B50C0000` and 58.50 MB at `BC220000` — are
+allocated at **boot**, before any menu, so 171 MB of the 379.5 MB is fixed
+regardless of route. The remaining ~208 MB is where a route difference could
+live, and the ledger can measure it: capture live-bytes at the moment TAKE OFF is
+pressed, for two different navigation paths, and compare.