ui+docs: the GUID token's real spelling, 40-yard interact, and the whole patch map

Working down the 29 `.tdata` hooks from the realm's patched `WoW.exe`.
Most turned out to be already ported; two were wrong here, and one of
those was wrong in a way that mattered.

**The GUID token was the wrong string.** `unit::guid_token` wrote 16
lowercase hex digits and no prefix. The realm writes `0x` + 16 upper-case
digits: its formatter at `0xd06500` — which `UnitExists`'s second return
goes through — lays down `0x30 0x78` then sixteen nibbles each `+0x37`
above 9, and its parser at `0xd06650` demands the `0x` and takes upper
case only. grom's own addons agree from the other end: BigWigs decides a
string is a GUID with `string.sub(guidOrName, 1, 2) == "0x"`
(`MageTools.lua:963`), and AI_VoiceOver reads fields from position 3 and
mints its own with `format("0x%04X%06X%06X", …)`.

Same number, wrong string, and wrong where it mattered most:
`UNIT_CASTEVENT` and the aura events carry these tokens, so every such
test read our GUIDs as unit *names* and every `sub(3, …)` field read came
out two characters off. Now written the realm's way; both spellings and
either case are accepted on the way in, since refusing one buys nothing.
Pinned literally rather than by round trip — a round trip held fine
through the whole bug.

**`CheckInteractDistance` type 4 is 40 yards, not 30.** `0x48bafd` jumps
to `0xd0686c`, which tests the type against 4 and compares against the
float the section carries at `0xd06868`: `1600.0`, squared thresholds.
Stock 1.12's `900.0` is still what the other three types use.

`docs/ADDON_COMPAT.md` now carries all 39 hook sites of both sections
with a status each: 10 in `.octoql` (one feature, the quest log, ported),
and 29 in `.tdata` — the aura ids, the master looter, `UnitExists`'s
GUID, the char-create mask and `CHAT_MSG_HARDCORE` already done; the two
challenge-mode functions needing nothing, because the realm's own
`ChallengeList.lua` defines them in Lua for exactly our case; four read
but unported with the reason (unnamed struct fields, no consumer in the
corpus); and three that cannot apply to a client that loads no DLLs.

Also `scripts/dll-surface.py`, which asks the injected DLLs the same
question. Their export tables are one `DllMain` each, but a DLL that
registers a Lua function must point at the name: collecting NUL-delimited
identifier strings the image holds a pointer to cuts `ClassicAPI.dll`
from 2872 CamelCase candidates to 706, and subtracting the 1.12 census,
Lua's own names and benilla's real surface leaves a candidate list the
addon corpus can rank. It is a list to read, not a specification —
statically linked libraries contribute their own strings, and
`UnitXP_SP3.dll` yields nothing. It found 38 names in `nampower.dll` that
grom's addons call and this file did not know about; they are written
down rather than guessed at.

269 data-gated failures, identical to the baseline, all nine gates green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SgstFWtn1RxEJ5kVrpgYwn

crates/benilla-ui/src/script/unit/mod.rs

@@ -308,14 +308,33 @@ pub struct UnitCastState {
 /// existing `String`-typed unit-token parameter here, which a raw 8-byte binary string would not
 /// reliably do.
 pub fn guid_token(guid: u64) -> String {
-    format!("{guid:016x}")
+    format!("0x{guid:016X}")
 }
 
-/// The inverse of [`guid_token`]: `None` for anything that isn't exactly 16 hex digits, so a real
-/// token name (`"player"`, `"party1"`, …) never misparses as a GUID.
+/// The inverse of [`guid_token`]: `None` for anything that isn't 16 hex digits, with the `0x`
+/// optional, so a real token name (`"player"`, `"party1"`, …) never misparses as a GUID.
+///
+/// The prefix is optional on the way **in** and always written on the way **out**, because the
+/// realm's own client writes it and addons test for it. Its formatter — `0xd06500` in the `.tdata`
+/// section of the patched `WoW.exe`, which `UnitExists`'s second return goes through — lays down
+/// `0x30 0x78` ("0x"), then sixteen nibbles each `+0x37` above `9`, so uppercase. Its parser
+/// (`0xd06650`, reached from the unit-token resolver at `0x515c14`) demands the `0x` and accepts
+/// `0`-`9` and `A`-`F` only. grom's own addons agree from the other side: BigWigs decides a string
+/// is a GUID with `string.sub(guidOrName, 1, 2) == "0x"` (`MageTools.lua:963`), and AI_VoiceOver
+/// both reads fields from position 3 and mints its own with `format("0x%04X%06X%06X", …)`.
+///
+/// This client used to write sixteen lowercase digits and no prefix, which is the same number and
+/// the wrong string: every such test read our GUIDs as unit *names*, and every `sub(3, …)` field
+/// read came out shifted by two. `UNIT_CASTEVENT` and the aura events carry these
+/// (`benilla-app`'s `ui_cast_events`, `ui_aura`), so it was wrong wherever it mattered most.
+/// Lower case is still accepted in, since nothing is gained by refusing it.
 pub(crate) fn token_guid(token: &str) -> Option<u64> {
-    (token.len() == 16 && token.bytes().all(|b| b.is_ascii_hexdigit()))
-        .then(|| u64::from_str_radix(token, 16).ok())
+    let body = token
+        .strip_prefix("0x")
+        .or_else(|| token.strip_prefix("0X"))
+        .unwrap_or(token);
+    (body.len() == 16 && body.bytes().all(|b| b.is_ascii_hexdigit()))
+        .then(|| u64::from_str_radix(body, 16).ok())
         .flatten()
 }
 

crates/benilla-ui/src/script/unit/tests.rs

@@ -1923,9 +1923,10 @@ fn superwow_guid_owner_and_mark_tokens_resolve() {
         .eval::<String>(r#"local _, guid = UnitExists("target") return guid"#)
         .unwrap();
     assert_eq!(
-        guid.len(),
-        16,
-        "a 16-hex-digit opaque id, guid_token's shape"
+        guid,
+        super::guid_token(42),
+        "`0x` + 16 uppercase digits, guid_token's shape — the form the realm's own client writes \
+         and addons test for with `sub(guid, 1, 2) == \"0x\"`"
     );
     assert_eq!(
         s.eval::<String>(&format!(r#"return UnitName("{guid}")"#))
@@ -2206,3 +2207,38 @@ fn pfuis_aggro_scan_walks_past_the_nameplate_tokens_to_reach_the_raid_ones() {
         "only the seated `player` exists; the point is that the walk reached `raid1` at all"
     );
 }
+
+/// The GUID token's exact spelling, against the three independent sources that fix it — the
+/// realm's own formatter, and two of grom's addons reading the other end.
+///
+/// Literal rather than round-tripped through [`super::guid_token`], which would assert nothing: a
+/// round trip held while this client wrote sixteen lowercase digits and no prefix, and every addon
+/// that tests `sub(guid, 1, 2) == "0x"` read those as unit *names*.
+#[test]
+fn a_guid_token_is_0x_and_sixteen_upper_case_digits() {
+    assert_eq!(
+        super::guid_token(0xF130_0000_04D2_0007),
+        "0xF130000004D20007"
+    );
+    assert_eq!(super::guid_token(42), "0x000000000000002A");
+    assert_eq!(super::guid_token(0).len(), 18);
+
+    // Accepted back with the prefix, without it, and in either case: nothing is gained by
+    // refusing a spelling, and the realm's own parser (`0xd06650`) takes upper case only.
+    for token in [
+        "0xF130000004D20007",
+        "0XF130000004D20007",
+        "F130000004D20007",
+        "f130000004d20007",
+    ] {
+        assert_eq!(
+            super::token_guid(token),
+            Some(0xF130_0000_04D2_0007),
+            "{token}"
+        );
+    }
+    // And a real token name is still never a GUID.
+    for name in ["player", "target", "party1", "nameplate1", "", "0x", "0xZZ"] {
+        assert_eq!(super::token_guid(name), None, "{name}");
+    }
+}