CDM: Change cd ready glow function to also check for is spell usable

[JuJuFX-dev]

Summary

The CD Ready Glow (pixelGlowReady / buttonGlowReady) previously activated
whenever a spell came off cooldown, regardless of whether the player had enough
resources to cast it. This caused the glow to fire even when e.g. Fury was too
low, which was misleading.

Changes

EllesmereUICdmHooks.lua only — two targeted edits, no other changes.

1. Deferred IsSpellUsable check on CD state change (SetDesaturated hook)

The existing pixelGlowReady/buttonGlowReady block now uses the same
one-frame defer pattern already used by hiddenOnCD/hiddenReady above it.
C_Spell.IsSpellUsable() is called one frame after SetDesaturated fires,
once the API has settled out of Blizzard's secure CDM chain. The glow only
starts if the spell is both off cooldown and usable.

2. Resource polling in the BuffTicker (10 Hz)

SetDesaturated only fires on cooldown state changes, not when resources drain
mid-fight (e.g. Fury falling below spell cost between casts). A lightweight
IsSpellUsable poll has been added to the existing BuffTicker loop, directly
after the existing stale _activeGlowOn cleanup block. This stops the glow
immediately when resources run out and restarts it when they recover.

Why IsSpellUsable instead of GetSpellPowerCost

GetSpellPowerCost returns cost = 0 for proc-based spells (e.g. Void Ray),
making it unreliable for resource gating. C_Spell.IsSpellUsable() correctly
reflects the game's own castability judgement for all spell types.

Behaviour

• Glow off → spell comes off CD but resources are insufficient → glow stays off
• Glow on → resources drain below cost mid-fight → glow turns off within ~100ms
• Glow off (resource-suppressed) → resources recover → glow turns back on
• Spells where IsSpellUsable returns nil (unknown to the API) are unaffected

Recreated the pull request cause of some problems with forked and local repo.

[EllesmereGaming]

hey! this is awesome and i really appreciate it, but while functional it has performance impacts that i'm not willing to compromise on at this time. Unconditional polling like this is something I try to avoid at all costs unless the feature is absolutely essential. if you can find a way to do this without impacting performance then I would be happy to add it!

[JuJuFX-dev]

hey! thank you for the feedback. I will start working on a less performance impacting solution and come back to you asap.

[JuJuFX-dev]

hey! this is awesome and i really appreciate it, but while functional it has performance impacts that i'm not willing to compromise on at this time. Unconditional polling like this is something I try to avoid at all costs unless the feature is absolutely essential. if you can find a way to do this without impacting performance then I would be happy to add it!

Hey, I just uploaded a new version with performance improvements and an improved function for the check. Feel free to check it out. If I get some more time, I’ll keep working on it and see if there’s still room for further optimization.