Fixed with client update. This bug is so dumb, it took me 8 hours to finally find its cause and fix it. If it had just been Azwan I wouldn't have cared, but it affects many other mobs in the game as well.
The bug is so convoluted, I can't help describing it here:
1. The client loads the mob template for 2500463 (right tower in Occupy/Hard/Party). This mob is linked to 2500420, meaning it takes all its animations etc. from that mob to avoid needlessly duplicating data.
2. So while loading 2500463, the client also loads 2500420. It then adds references to all properties of 2500420 except "info" into 2500463. This causes 2500463 to have a different layout in memory than on disk. This in itself isn't bad, it's actually pretty smart and simplifies code in other areas of the client. It will become important later on though.
3. Once the mob is in range on the screen and wants to do attacks, the client loads the attacks. The little thingies that shoot out of the floor are called areaWarning. While loading the attack, the client simply stores the path of where to find the areaWarning animation in the object for the attack: Mob/2500463.img/attack2/info/areaWarning. This string is then used to find the data whenever the animation should be shown.
4. When changing maps* or at the latest after 120 seconds, the client tasks WzResMan with cleaning up loaded WZ data and evicts both 2500420.img and 2500463.img from cache.
5. Tower does its attack again and requests object "Mob/2500463.img/attack2/info/areaWarning". Mob/2500463.img is not in cache and is loaded from file. After it's loaded, WzResMan reports that the requested object was not found in the archive. What happened? Well, step 2 was not executed this time so 2500420 wasn't linked into 2500463, and attack2 doesn't exist in 2500463.img.
6. Congratulations, your attack is now invisible.
Getting to this point actually didn't take me that long, but I then got hung up figuring out what happened that it suddenly exhibits this behavior post-RED. After firing up a v142 instance of Croosade and checking there, I finally saw it: Before RED, the path that was stored for the attack animation was actually "Mob/2500420.img/attack2/info/areaWarning". So it took the linked mob's ID, which can be reloaded just fine even after a cache flush.
Why is the behavior different? It seems Nexon wanted to have the possibility to override attack animations in copied mobs. So it could, say, take a special version of attack2 from the copied mob, and all other animations from the original (link target) mob. The actual bug lies in the check if attack2 exists in the copied mob: Remember in step 2 it links data from the original mob. It will always find attack2, because at that point is has no way to tell apart where attack2 is actually defined, because the data was tampered with in memory! That's why it formats the wrong ID into the animation path string.
It appears this particular bug is fixed in current GMS now, but it took Nexon years to figure it out themselves.
*This is actually another stupid thing I discovered while debugging this: Whenever you leave a map, the client flushes all parsed WZ data for things commonly needed like status bar, game UIs, equips you wear etc. from cache. But - and get this - it only does so if you're not running Windows 2000 or XP. Hahaha literal retards! I'm patching this out as well. Should give a tiny boost when changing maps, especially on lower-end systems.