re: the waited object reads as an xe::kernel::XEvent

Executed the wait-object read on a live run under gdb. For every thread whose
frame 3 is XObject::Wait, rbx gives a pointer whose first quadword is
0x5555562db8f0, which is the PIE base plus 0xd878f0, and the symbol table has
vtable for xe::kernel::XEvent at 0xd878e0. The stored pointer is the vtable
symbol plus sixteen, since offset-to-top and RTTI come first, so it matches
exactly. The same vtable appears on every sampled waiting thread while the this
pointers differ, meaning many threads waiting on different XEvent instances. The
whole chain needs no DWARF and no rebuild, as the static groundwork predicted.

Two caveats, both recorded rather than smoothed over.

This is a healthy-play snapshot, not the freeze. The capture landed at 195 s of
flight with screen_id reporting flight and a non-black mean, because boot under
gdb costs about 300 s and the entire experiment has to fit inside one call --
a timeout kills the process group and takes the emulator with it, which lost an
earlier attempt outright. So this describes what threads wait on during normal
play, which is the control the frozen capture never had, but it is not the
frozen case.

And the this addresses look like host stack rather than heap. Either xenia
places these objects somewhere unusual, or rbx at frame 3 is not Wait's this
after the unwind and the vtable match is coincidence. An exact plus-sixteen
match on a known symbol is hard to get by accident, but the address range is not
what was expected. The settling check is to dump a few words at rbx and see
whether they look like an XEvent -- vtable, KernelState pointer, handle and type
fields -- or like saved registers.

docs/re/BACKLOG.md

@@ -719,6 +719,19 @@ search cannot find a *schedule*.
   **Revises the previous entry**, which called route 1 "per-frame archaeology"
   and route 2 (RelWithDebInfo rebuild) the way to make it easy. **Next: execute on
   a frozen run** — two gdb commands per thread.
+* ✅🟡 **(2026-08-25) Wait-object read WORKS: the object is an `xe::kernel::XEvent`.**
+  Executed under gdb: `frame 3` → `rbx` → `x/1gx $rbx` = **`0x5555562db8f0`** =
+  PIE base + `0xd878f0` = **`vtable for xe::kernel::XEvent` (+16 for
+  offset-to-top/RTTI)** — exact. Same vtable on every sampled waiting thread,
+  different `this` each, so many threads waiting on *different XEvent instances*.
+  No DWARF, no rebuild, as predicted. 🟡 **Two caveats, both recorded not glossed:**
+  (1) this is a **healthy-play** snapshot (`screen_id` = `flight`), not the freeze
+  — boot under gdb costs ~300 s and the whole thing must fit one call (a `timeout`
+  kills the process group and took the emulator with it once), leaving too little
+  to reach the ~267 s freeze; (2) the `this` addresses (`0x7ffd…`, `0x7ffc…`) look
+  like **host stack**, not heap, so either xenia places them unusually or `rbx`
+  isn't `Wait`'s `this` after unwind. **Check: dump a few words at `$rbx` —
+  XEvent-like (vtable, KernelState*, handle) vs saved registers.**
 * ~~🚧 BLOCKER: t=210/240 unreachable in one turn~~ — **superseded, see above**;
   it rested on an untested assumption that a turn is one shell call. 595 s shell cap − ~220 s boot (a ~190 s title movie that cannot be
   tapped through) − ~25 s startup = **~350 s observation ≈ 193 game-seconds**.