re: the allocation failure is definitively not the freeze -- four runs, three outcomes

Four runs now freeze at the first content load after the main menu with three
different allocation outcomes: stock (fails at 128 MB and throws), GPU-writeback
patched (no failure, stops at 32 MB), heavy XMA logging (no failure, stops at
16 MB), and no-savegame (no failure, no throw).  The memory account on this page
is accurate but describes a symptom; everything treating the 128 MB refusal as
the freeze is superseded.

The savegame is not the variable.  --content_root pointed at a profile-only tree
(the real content untouched) boots to the identical pools -- BC220000 Size
03A80000 and B50C0000 Size 070E0000, same addresses and sizes, same 43
allocations by the menu -- then freezes at the same press with zero failures.

Not slow shader compilation either.  Every earlier run called it frozen within
~30 s; this one was left six minutes at 0.00% liveness with CPU still 399-479%.

Correction made mid-measurement: the allocation counter creeping 119->124 looked
like "guest running, display stuck".  It is not.  A broad sample -- 400 extents,
8.2 MB -- changed 18 bytes in 3 seconds.  The guest is spinning, with one thread
allocating about once a minute.  The earlier "8 MB slab unchanged" reading was
weak for the same reason in reverse: one arbitrary region proves little.  Sample
broadly before calling a guest alive or dead, exactly as the screen needed two
frames rather than one.

Now excluded: the heap failure, the leak, rounding, MmQueryStatistics, a
heap-size knob, the exception cvar, a kernel-object wait, a build regression, the
route, the savegame, and shader compilation.

docs/re/mission-freeze-heap-exhaustion.md

@@ -617,3 +617,59 @@ The next thing to vary is therefore the **boot inputs**: profile, save data and
 `xenia-canary.config.toml`. `B50C0000`'s request is `0x070D28B0` — an odd,
 computed size, not a round reservation — so it plausibly depends on something
 configurable.
+
+---
+
+# 🔴 The allocation failure is definitively **not** the cause
+
+Four runs now freeze at the same point — the first content load after the main
+menu — with three different allocation outcomes:
+
+| run | change | allocation outcome | froze? |
+|---|---|---|---|
+| stock | — | **fails** at 128 MB, guest throws | yes |
+| GPU writeback 16 MB → 1 MB | emulator patch | none, stops at 32 MB | yes |
+| heavy XMA debug logging | logging | none, stops at 16 MB | yes |
+| **no game save** (`--content_root` to a profile-only tree) | boot input | **none, no throw** | yes |
+
+The memory account on this page is accurate and still worth having, but it
+describes a **symptom**. Everything above that treats the 128 MB refusal as the
+freeze is superseded by this table.
+
+## 🔴 The savegame is not the variable either
+
+`--content_root=/tmp/content-nosave-a`, containing a copy of the profile and no
+game save (the real content tree untouched), boots to the **identical** pools:
+`BC220000 Size: 03A80000` and `B50C0000 Size: 070E0000`, same addresses, same
+sizes, same 43 allocations by the menu. Then freezes at the same press, with
+**zero** allocation failures and **zero** throws.
+
+## ✅ It is not slow shader compilation either
+
+Every earlier run called it frozen within ~30 s. Under lavapipe a content load
+could plausibly be compiling shaders, so this one was left for six minutes:
+
+    t+1min  liveness 0.00%   allocs 121   cpu 479%
+    t+2min  liveness 0.00%   allocs 122   cpu 461%
+    ...
+    t+6min  liveness 0.00%   allocs 124   cpu 399%
+
+No recovery, and no sign of one.
+
+## ⚠️ And a correction I made mid-measurement
+
+The allocation counter creeping (119 → 124) briefly looked like "the guest is
+running, only the display is stuck". **It is not.** A *broad* guest-memory
+sample — 400 extents, 8.2 MB — changed **18 bytes in 3 seconds**. The guest is
+stuck; one thread still allocates roughly once a minute at 400 % CPU, which is a
+spin, not progress.
+
+The earlier "8 MB slab at `0x40000000` unchanged" reading was also weak evidence
+for the opposite reason — one arbitrary region proves little either way. **Sample
+broadly before calling a guest alive or dead**, the same way the screen needed
+two frames rather than one.
+
+❔ So the oracle is still broken and the cause is unidentified. What is now
+excluded: the heap failure, the leak, allocation rounding, `MmQueryStatistics`,
+a heap-size knob, the exception cvar, a kernel-object wait, a build regression,
+the navigation route, the savegame, and slow shader compilation.