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/compat/classic_api/creature_info.rs

@@ -405,9 +405,10 @@ mod tests {
         let s = seeded();
         // HIGH_UNIT (0xF130) in the top 16 bits, entry 1234 at bits 24-47.
         let creature: u64 = (0xF130u64 << 48) | (1234u64 << 24) | 7;
+        let token = crate::script::guid_token(creature);
         assert_eq!(
             s.eval::<i64>(&format!(
-                r#"return C_CreatureInfo.GetCreatureID("{creature:016x}")"#
+                r#"return C_CreatureInfo.GetCreatureID("{token}")"#
             ))
             .unwrap(),
             1234

crates/benilla-ui/src/script/compat/classic_api/nameplate.rs

@@ -214,7 +214,7 @@ mod tests {
             .unwrap();
         assert_eq!(guids.len(), 2);
         assert!(
-            guids.iter().all(|g| g.len() == 16),
+            guids.iter().all(|g| g.len() == 18 && g.starts_with("0x")),
             "16-hex-digit tokens, the same shape UnitGUID hands out: {guids:?}"
         );
 

crates/benilla-ui/src/script/compat/classic_api/tooltip.rs

@@ -875,7 +875,7 @@ mod tests {
         assert_eq!(
             s.eval::<(String, String)>("return tip:GetUnitGUID()")
                 .unwrap(),
-            ("Hogger".to_string(), "00000000deadbeef".to_string()),
+            ("Hogger".to_string(), "0x00000000DEADBEEF".to_string()),
             "the name and the 16-hex-digit guid token, in GetUnit()'s two-value shape"
         );
         // The second value is what pfUI feeds `UnitTokenFromGUID`, so it has to round-trip.
@@ -890,7 +890,7 @@ mod tests {
         assert_eq!(
             s.eval::<String>("local _, g = tip:GetUnitGUID() return g")
                 .unwrap(),
-            "00000000deadbeef",
+            "0x00000000DEADBEEF",
             "still Hogger's guid: the tooltip is still showing Hogger"
         );
         assert_eq!(

crates/benilla-ui/src/script/compat/classic_api/unit.rs

@@ -99,7 +99,9 @@ mod tests {
         );
 
         let guid = s.eval::<String>(r#"return UnitGUID("target")"#).unwrap();
-        assert_eq!(guid.len(), 16);
+        // "0x" + 16 digits: the realm writes `0x` + 16 uppercase digits (`unit::guid_token`).
+        assert_eq!(guid.len(), 18);
+        assert!(guid.starts_with("0x"));
         assert_eq!(
             s.eval::<String>(&format!(r#"return UnitTokenFromGUID("{guid}")"#))
                 .unwrap(),