have you been able to reproduce it on your local machine? You can run two clients on a single machine and play against them in LAN:
- Launch your first instance of wc3 from the battle.net app
- Launch a second instance of wc3 from the battle.net app--either this instance or the first one will show a message saying an error occurred, and just select "Play Offline"
- Start a game via local area network and choose your map--then go on the other client and join it
The most important thing in fixing desyncs is reproducibility. If you don't have a way to semi-reliably reproduce it, then all your fixes will be stabs in the dark and you won't know if anything is actually being fixed!
Once you have a semi-reliable reproduction locally, try to see if you can make the reproduction happen as fast as possible--e.g. maybe add a chat command "-cheatlol" to just give yourself super buff heroes and teleport them to the Fire Golem/Penguin King and see if you can still reproduce it. This, sadly, doesn't always work because desyncs can be caused by a weird, complex butterfly effect--but it is worth trying to make your testing less painful.
If you get to that point where you have a semi-reliable reproduction, that is the point where you should divide-and-conquer--start off with testing a version that has all custom models and textures deleted => run it several times to see if it desyncs or not. If it still desyncs, then that likely isn't the culprit. So then you can move on to triggers => delete as many as possible (I would recommend trying a run without ANY triggers in the map, because that'll at least help you confirm that the desync has to do with triggers). The main goal is to narrow down the category, and then you can at least have confidence knowing you can brute-force your way into a solution.
That being said, I looked at your map and I didn't notice anything obviously wrong with the triggers--usually I'll try to hunt down faulty uses of GetLocalPlayer(), GetLocationZ(), or other async functions. The only code using that AFAIK is the MMD system and CinematicModeWithoutChangingFog function. I would recommend trying a run with MMD disabled (and maybe one run with that cinematic mode function disabled, but I doubt that is it).
Otherwise, I'd try going through this list and seeing if any of the bullets match your cases:
Introduction Players should be able to differentiate a crash, a player leaving and a player being desynchronized. Desync is the fact that one or more player gets disconnected from a online multiplayer game. It's caused by differences in the game state between the game clients. Below I tried...
www.hiveworkshop.com
for example, the "player slot comparisons" and "player controller comparisons" (I haven't personally ran into issues with those, but it is worth checking). Hope you can find out the cause of the issue, desyncs are always super painful to debug.