isl: rename built-ins 8/9/93 to stopwatch_start/_elapsed/_stop

They are start / read / stop of one of 32 per-phase stopwatches, not
flag operations.  123-127 keep timer_* -- that is the mission timer,
five scalars at [phase+304..320], a different clock.

Artefact check: 84 lines changed across 5 files and all 84 pair
exactly with their old-name partners once column padding is
normalised (0 removed lines without an old name, 0 added lines
without a new one).  data/isl-timers.txt reproduces the same
675/675, 11.2 % control, 82/1 and identical histograms, which is
what shows the rename is cosmetic.

Also withdraws a label from the previous commit: sub_8230C398 is NOT
the message pump.  It runs every frame but drains nothing -- a state
machine on [0x828E1F8C] that only allocates, builds strings, looks up
and PUSHES.  And bus+8216 is weak evidence: sub_82254A08 is a generic
map find with ~120 sites, and the key looked up is a pointer, not a
tag.  The open handle is now the ring buffer at bus+4, not bus+8216.

docs/re/BACKLOG.md

@@ -364,6 +364,31 @@ unknown, what evidence exists, and what the first step would be. Move an item in
   into `bus+8216` and with which key**. That path is unread, so **the item is NOT
   settled**: whether running out of time ends the mission is still unknown.
 
+* ✅🔴 **(2026-08-27) THE STOPWATCH BUILT-INS ARE RENAMED — and my own "message
+  pump" label from the previous pass is WITHDRAWN.**
+  ✅ **Rename landed.** `isl.py` emits **`stopwatch_start` (8) /
+  `stopwatch_elapsed` (9) / `stopwatch_stop` (93)**; 123–127 keep `timer_*` for
+  the mission timer, which is five scalars rather than a 32-entry bank. Artefact
+  check: **84 lines changed across 5 files, and all 84 pair exactly** with their
+  old-name partners once column padding is normalised — 0 removed lines without
+  an old name, 0 added lines without a new one. `data/isl-timers.txt` regenerates
+  to the **same** 675/675, 11.2 % control, 82/1 and identical argument
+  histograms, which is the check that the rename is cosmetic.
+  🔴 **WITHDRAWN: "`sub_8230C398` is the per-frame message pump."** It *is*
+  called every frame (`sub_821A6470` at `0x821A654C`, `sub_821AA1B0` at
+  `0x821AA7DC`, both with `dt`) but it **drains nothing** — its body is a state
+  machine on `[0x828E1F8C]`, and over 466 instructions it calls only an allocator
+  `sub_8230C160`, string building `sub_8217FA08`, the lookup `sub_823001E8` and a
+  *push* `sub_8225FEA0`. A boot/loading sequencer that POSTS messages.
+  🔴 **And `bus+8216` is weaker evidence than I wrote.** `sub_82254A08` is a
+  generic map find with **~120 call sites image-wide**, and `+8216` is a common
+  offset (50+ `addi …, 8216` sites); worse, **the key `sub_823001E8` looks up is
+  a POINTER** (`lwz r4, 13780(r11)`, stored and passed by address), **not a
+  message tag** — so that map may not be the subscriber registry at all.
+  ▶️ **The item is still open and the handle is now different**: find what drains
+  the ring buffer at `bus+4` (capacity `+8`, head `+12`, count `+16`), not what
+  reads `bus+8216`. Whether running out of time ends the mission is unanswered.
+
 ## ✅✅ SOLVED — the mission freeze was a modal sign-in dialog (2026-08-26)
 
 `XamShowSigninUI` opens a modal dialog and `xeXamDispatchDialog` blocks the