isl: built-in 104 is request_next -- named from the game's own log string

Followed the writer, not the reader.  [phase+10160]'s only writer in
the image is one site in the mission frame loop sub_821AA1B0: it does
obj->get() on an object fetched from a registry by id 0x20FFFF02,
stores it to the phase, then clears the object -- read, publish, clear,
every frame.

The id namespace has exactly three members (0x20FFFF00/01/02), each
built at exactly 4 sites, and two of those are in sub_821D5178, which
gets 0x20FFFF01 and 0x20FFFF02 and logs both:

  GamePart_ReadyRoom::Impl::OnCommand - Wait() command is requested.
  Check flow control valiables. WAIT_MODE : %d, REQUEST_NEXT : %d

Argument order gives 0x20FFFF01 = WAIT_MODE, 0x20FFFF02 = REQUEST_NEXT.
PrepareScript corroborates: it sets WAIT_MODE=1, REQUEST_NEXT=0 before
an ISL script runs.  So the six tutorial stages' lone dominating
condition request_next() != 1 is the script waiting on the game part's
proceed flag.

6 artefact lines changed, all 6 pair exactly.

docs/re/structures/isl-condition-builtins.md

@@ -40,8 +40,53 @@ which is exactly why their exits have one dominating condition each and why
 ```
 
 inside `sub_821AA1B0`, gated on a type/kind field being in `(16, 32]`. `r29`
-there comes from `or r29, r3, r3` — the return of a preceding call — so **what
-the value means is not established**, and neither is what the gate selects.
+there comes from `or r29, r3, r3` — the return of a preceding call.
+
+## ✅ (2026-08-27) NAMED — built-in 104 is `request_next`, and the game says so itself
+
+`r29` is the return of a **getter on an object fetched from a registry by id**:
+
+```
+821AAD1C  lwz  r4, 2424(r30)        ; the registry
+821AAD20  addis r5, r0, 0x20FF
+821AAD28  ori   r5, r5, 0xFF02      ; <- the id
+821AAD38  bcctrl                    ; registry->slot1(&out, 0x20FFFF02)
+821AAD40  lwz  r11, 0(r3) ; lwz r11, 8(r11)
+821AAD4C  bcctrl                    ; r29 = obj->slot2()      -- GET
+821AAD9C  stw  r29, 10160(r11)      ; -> [phase+10160]
+821AADA0..DD4                       ; then the SAME id again, obj->slot1(0)  -- CLEAR
+```
+
+So the frame loop **reads the value, publishes it to the script, and clears it**.
+
+**The id namespace has exactly three members** — `0x20FFFF00`, `0x20FFFF01`,
+`0x20FFFF02` — each built at exactly 4 sites image-wide. Two of those sites are
+in `sub_821D5178`, which fetches `0x20FFFF01` and `0x20FFFF02`, calls the same
+`slot2()` getter on each, and passes both to a log call whose format string is
+at `0x820A4968`:
+
+> `silph::GamePart_ReadyRoom::Impl::OnCommand - Wait() command is requested.`
+> `Check flow control valiables. WAIT_MODE : %d, REQUEST_NEXT : %d`
+
+Argument order settles which is which: `r4` (first `%d`, **WAIT_MODE**) is
+`0x20FFFF01`'s value, `r5` (second, **REQUEST_NEXT**) is `0x20FFFF02`'s.
+
+> ⇒ **`[phase+10160]` is `REQUEST_NEXT`, and built-in 104 returns it.**
+
+That is the game's own name for the variable, not a shape-based guess.
+Corroboration: `GamePart_ReadyRoom::Impl::PrepareScript` sets `WAIT_MODE = 1`
+and `REQUEST_NEXT = 0` before an ISL script runs, and `sub_821AA1B0` clears both
+each frame after reading. `[phase+10160]` has **exactly one writer and one
+reader** in the whole image (the two above); the three other hits on offset
+10160 are `lfs` on unrelated objects.
+
+So the six tutorial stages' exit condition `request_next() != 1` is the script
+waiting on the surrounding game part's *proceed* flag — which is why S18–S23
+each have exactly one dominating condition.
+
+🟡 Still unread: what the `(16, 32]` gate on `[r30+104]`'s `+12` selects, and
+`0x20FFFF00`, the third id (used by the `GRAPH_PATH` / `EX_FONT` / `SYSTEM`
+code in `sub_821D6350` and `sub_821D6A40`).
 
 🟡 Its neighbours belong to the same cluster: `builtin103` reads
 `[phase+10156]` and `[phase+10152]` (9 and 7 writers), and a sibling vtable stub