docs/re: more UI map, no walk — and say that this is becoming a rabbit hole

Three facts, none of them the thing being looked for:

* the drawing API is enumerable — the renderer accessor the quad emitter uses has
  exactly 6 callers, four of them sibling quad emitters;
* sub_823C2990 is a FACTORY, not the singleton accessor its use in the top-level
  render function suggested: it allocates 4 bytes plus a 244-byte object from the
  heap at [0x828E2B14] and runs the chain that ends at the constructor installing
  vtable 0x820b30b4. So a UI item is 244 bytes;
* the 0x823C region holds both the item class and four of the RATC-fourcc
  loaders, so bundle parsing and item construction live together.

And the part worth writing down more than any of them: three iterations have
added map without answering the question, and each step has been a plausible next
query rather than a decisive test — the shape of a search that can run forever.
The decisive alternative is costed instead of started: a Canary memory watch on
the UI vertex buffers would report the guest PC that writes them, naming the
emitter and its caller outright. That is real emulator work, and it is now a
choice to weigh against leaving the paint order unresolved, which costs the port
one screen's fidelity and nothing else.

docs/re/ui-quad-class-foothold.md

@@ -76,3 +76,45 @@ Two reasons, neither of which is "it looks right":
 **Not settled:** everything the search was actually for. No function that
 iterates screen elements has been found, and nothing here bears on the paint
 order yet.
+
+## Second pass: the drawing API is small, and a UI item is 244 bytes
+
+Continuing the search for the element walk (2026-08-19). Three more facts, none
+of which is the walk:
+
+* **The drawing API is enumerable.** The renderer accessor `sub_823C2AC0` — the
+  one the quad emitter calls to get its vertex pointer — has exactly **6
+  callers**, and four of them (`sub_821D6A40`, `sub_822380B0`, `sub_82234610`,
+  `sub_821BC718`, ~160 instructions each) are sibling quad emitters. So the
+  number of places in the whole title that can emit a UI quad is small enough to
+  enumerate, which is worth knowing before instrumenting anything.
+
+* **`sub_823C2990` is a factory, not a singleton accessor** — a correction to
+  what its use inside the top-level render function suggested. It allocates twice
+  from a heap held at `[0x828E2B14]` via `sub_82150EF8`: 4 bytes for a handle,
+  then **244 bytes** for the object, and runs `sub_823DE0C0`, which is the head
+  of the chain that ends in `sub_823CB2A0` — the constructor that installs
+  vtable `0x820b30b4`. So **a UI item object is 244 bytes**, and the "LOGO item"
+  class named in the emulator-era notes is what this factory builds.
+
+* **The `0x823C…` region is the screen/bundle subsystem.** It contains both the
+  item class (constructors at `823CB2A0/823CB558/823CBB90`, methods
+  `823CE558…823CFD90`) and four of the functions that load the `RATC` fourcc
+  (`823CAF10`, `823CABE0`, `823CB1F0`, `823CBEE8`), so bundle parsing and item
+  construction live together.
+
+## Stated plainly: this is becoming a rabbit hole
+
+Three iterations have added map without answering the question. The searches keep
+landing on *construction* and *emission*, never on the per-frame walk that orders
+elements — and each step is a plausible next query rather than a decisive test,
+which is the shape of a search that can run indefinitely.
+
+The decisive alternative, costed rather than started: the vertex buffers the
+capture already records (`vb=0x14D10B90`, …) are written by the **guest CPU**
+just before the draw. A Canary memory watch on that range would report the guest
+**PC** doing the writing, which names the emitter and its caller directly instead
+of inferring them. That is a real change to the emulator (the watch machinery
+exists for shared-memory invalidation, not for reporting PCs), so it is the next
+thing to weigh — against simply leaving the paint order unresolved, which costs
+the port one screen's fidelity and nothing else.