creature_anim: SuperWoW's LootSparkle, the sparkle on lootable treasure

1.12 sparkles a lootable corpse and nothing else — a chest, a herb, a vein or a
quest object is found by eye. Sparkling those arrived in 2.3.0 ("interactable
game objects sparkle and display their names") and SuperWoW backports it as
`LootSparkle`, which upstream describes as "the sparkling effect on lootable
treasure". So on this install the sparkle appears on mobs and not on objects,
which is what was reported.

`arm_loot_fx` grows a GameObject arm beside its unit and corpse ones, hanging the
same "HARDCODED Loot Art" row (0x13) at the same tag, driven by the same field
edges. The three-way decision is a named predicate with a test, because a corpse
falling into the unit arm would read its CORPSE_* bytes as a live unit's, and
because the switch being off has to answer *exactly* 1.12 rather than
approximately it.

The object test has two arms, because the mod's own phrase is "lootable treasure"
and neither arm alone is that:

- `GO_DYNFLAG_LO_ACTIVATE`, the server's per-viewer bit, documented on its own
  field reader as "the sparkle". But vmangos raises it through
  `GameObject::ActivateToQuest`, so on a chest it means *quest* loot: an ordinary
  chest, herb or vein need never carry it, and keying on it alone risks lighting
  up nothing but quest objects.
- `GAMEOBJECT_TYPE_CHEST`, which is exactly chests, herbs and mining nodes —
  treasure by construction, and a type the client reads without the server's
  help. Excluded when `GO_FLAG_IN_USE` or `NO_INTERACT` is set, so an emptied or
  disabled chest stops sparkling.

Both arms are a judgement about what the mod does rather than a trace of it —
there is no source and no published default — so they are written to be read and
corrected, and the predicate's own doc says which symptom indicts which arm: only
quest objects lighting up means the first is doing all the work, doors and signs
lighting up means the second is too wide.

Defaulted on: upstream publishes no default, and the sparkle is present on this
install with SuperWoW loaded, which is what "as if its own default config loaded"
means for this compat layer. `SetCVar("LootSparkle", "0")` is stock 1.12.

**Not verified in world.** The harness has no scene, so the test covers the
decision and not the rendering.

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

docs/ADDON_COMPAT.md

@@ -41,7 +41,8 @@ nothing behind it.
 | `ChatBubbleRange` | done | `chat_bubble.rs`'s `BubbleConfig::range_sq`, replacing the reference's hardcoded 20 yd. Default `20` (today's exact value) — no shipped default published for this one either, within the mod's documented 10-200 yd range |
 | `NameplateMotion`, `NameplateVerticalSpacing` | todo | needs locating whatever (if anything) already staggers overlapping nameplates, not investigated |
 | `FoV` | todo, held back | the wiki's only confirmed default (`"1.57"`) doesn't obviously match benilla's existing hardcoded `benilla-world/src/view.rs`'s `CAM_FOVY = FRAC_PI_4` (0.785 rad, 45°) — 1.57 rad is 90°, double. Without confirming whether SuperWoW's `FoV` cvar and `CAM_FOVY` share the same angle convention (vertical half vs. full, radians interpretation) and whether 1.12's true default really is 45°, defaulting to the wiki's literal `1.57` risks a jarring, wrong-looking lens change rather than exposing the existing value as a tunable knob. Left alone rather than guess |
-| Healing text, uncap sounds, selection-circle style, loot sparkle, outline/shadow text, force-show-auras, XP text | todo | not investigated |
+| `LootSparkle` | done, CVar `LootSparkle`, default `1` | `creature_anim/spell_visual.rs`'s `arm_loot_fx` grew a **GameObject** arm beside its unit and corpse ones, hanging the same `"HARDCODED Loot Art"` row (`0x13`) at the same tag. 1.12 sparkles a lootable corpse and nothing else — a chest, a herb, a vein or a quest object is found by eye — and sparkling those arrived in **2.3.0** ("interactable game objects sparkle and display their names"), which is what the mod backports: upstream describes it as "the sparkling effect on lootable treasure". The test is the server's own per-viewer `GO_DYNFLAG_LO_ACTIVATE` in `GAMEOBJECT_DYN_FLAGS` (`GameObject::ActivateToQuest`), already parsed and already documented on its field reader as "the sparkle", so what lights up is exactly what this character can currently use rather than every door and sign in the zone — and the rising and falling edges of that bit are the whole trigger, which is also how the corpse arm works. Defaulted **on**: upstream publishes no default, and the sparkle is present on this install with SuperWoW loaded, which is what "as if its default config loaded" means here; `SetCVar("LootSparkle", "0")` is stock 1.12. `FxStage` is `OneShot` for an object as for a corpse — neither has a sequence of ours to loop, where a unit's loot art loops its first (`0x600640`) |
+| Healing text, uncap sounds, selection-circle style, outline/shadow text, force-show-auras, XP text | todo | not investigated |
 | Macro limit 255→510 | done | `script/macros.rs`'s `MAX_MACRO_BODY`; `ui_script/manifest.rs`'s `install_macro_letters_patch` re-patches the stock FrameXML's `SetMaxLetters`/char-count string at boot, since both come from the player's own install |
 | Targeting-circle spells (Blizzard, Flamestrike) no longer refuse movement | done | `cast_target::is_ground_targeted` (`spell/cast_target.rs`) exempts them in `validator::cast_moving_refusal` (`spell/validator.rs`); the real cast-time interrupt-on-move rule (`inflight.rs`) is untouched |
 | Ranged abilities (Aimed Shot) firing `SPELLCAST_START` | done | already satisfied — `spell/net.rs`'s `spell_start` already opens the bar on any real `SpellCastTimes.dbc` duration rather than the reference's narrower ranged-spell suppression (see the `has_cast_time` comment there); confirmed by the existing test `a_timed_ranged_cast_opens_the_shot_bar_but_an_instant_shot_does_not` |