re: the freeze's 512 MB is the emulated console's, not the host's

"Allocation failed" invites blaming the box, so I measured the box.  Nothing on
the host side is binding: /dev/shm is 2.0 G at 17% used with 1.7 G free (the
guest memory file is 4.5 G apparent but sparse, only 319 MB of real blocks),
host RAM has 12.3 G available of 15.9, and the container cgroup is at 2.9 G of a
7.0 G limit.

The log's own numbers say where it really is:

    131072 pages x 4 KB = 512 MB      <- the Xbox 360's unified memory, exactly
     28969 pages x 4 KB = 113 MB free
              0x08000000 = 128 MB requested

So "parent heap" is the emulated console's physical memory.  The game runs a
real 512 MB console down to 113 MB free and then asks for 128 MB; the container
is not involved.

Mechanism, recorded as amber rather than settled: 23 and 22 occurrences of
"BaseHeap::Release failed because address is not a region start" in the two
runs, adjacent to the failure (lines 1115-1176 against a failure at 1179).  A
release that cannot find its region start returns without freeing, so each leaks
guest physical pages.  That is inference from adjacency and count -- I have not
sampled free pages over time, which is the test that would settle it.

And the release failing at all is an emulator-side bug, not a game one: the
guest is freeing at an address Xenia's heap does not recognise as a region base.

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

@@ -97,3 +97,53 @@ RAM, before believing an empty result means "the thing is not there".
 
 ❔ Still open: why the guest needs a single 128 MB block, whether the heap can be
 given more, and whether the failure is reachable without the mask poke at all.
+
+## ✅ It is the *emulated console's* 512 MB, and the host is not short
+
+Worth ruling out explicitly, because "allocation failed" invites blaming the box:
+
+| resource | measured at the freeze | binding? |
+|---|---|---|
+| `/dev/shm` (backs guest memory) | 2.0 G, **17 % used**, 1.7 G free | no |
+| host RAM | 15.9 G total, **12.3 G available** | no |
+| container cgroup `memory.max` | **2.9 G of 7.0 G** | no |
+| **emulated console RAM** | **113 MB free, 128 MB wanted** | **yes** |
+
+The guest memory file is 4.5 GB *apparent* but sparse — only **319 MB of real
+blocks** — so the 2 GB `tmpfs` was never close to full either.
+
+The decisive arithmetic is in the log's own numbers:
+
+    131072 pages x 4 KB = 512 MB      <- the Xbox 360's unified memory, exactly
+     28969 pages x 4 KB = 113 MB free
+              0x08000000 = 128 MB requested
+
+So `parent heap` is **the emulated console's physical memory**, not anything of
+the host's. The game runs a real 512 MB console down to 113 MB free and then asks
+for 128 MB. Nothing about the container is involved.
+
+## 🟡 The likely mechanism: a release path that leaks
+
+Immediately before the failed allocation, in **both** runs:
+
+| run | `BaseHeap::Release failed because address is not a region start` |
+|---|---|
+| poked, Stage 02 | **23** |
+| control, Stage 01 | **22** |
+
+and they are adjacent to it — in the control run they sit at lines 1115–1176 with
+the allocation failure at line 1179. A release that cannot find its region start
+returns without freeing, so each one leaves guest physical pages permanently
+claimed. Twenty-odd of those over a session is a plausible route from 512 MB down
+to 113 MB.
+
+🟡 Plausible, not shown: I have not measured free pages *over time*, only at the
+moment of failure, so "the leak causes the exhaustion" is still an inference from
+adjacency and count. The test that would settle it is to sample the heap's free
+page count through a run and see whether it falls in steps that coincide with the
+failed releases.
+
+❔ And the deeper question is why the release fails at all — `address is not a
+region start` says the guest is freeing something at an address Xenia's heap does
+not recognise as a region base, which is an **emulator-side** bug rather than a
+game one.