Pathfinder::moveAllies walks a path that a nested move-away of the same unit has already destroyed

[bobtista]

Pathfinder::moveAllies can continue walking a path after a nested move-away order destroys it.

Unit A orders B out of the way. B's own path walk orders A to move away, and A calls destroyPath() on the path the outer walk is still using. The outer walk then continues over freed nodes.

This can crash or change which allies get ordered to move, depending on what happens to the freed memory. Earlier testing with freed-memory poisoning exposed both outcomes.

[VS22 replay: 3323-moveallies-reentry.zip](https://github.com/user-attachments/files/32566939/3323-moveallies-reentry.zip)

Recorded with the automated LAN harness: Twilight Flame, two human GLA players and five hard AI.

To Reproduce:

1. Play the replay on a stock VS22 Release build from e4017100cd.
2. At frame 27111, watch Demo Scorpion 15538 order Demo Quad Cannon 14444 out of the way.
3. The Quad's walk orders the Scorpion to move away. The Scorpion's privateMoveAwayFromUnit destroys the path its outer moveAllies call is still walking.

This replay reproduces the freed-path access, not a Release crash. The base build finishes all 36540 frames without a CRC mismatch.

[bobtista]

five more replays from the long replay set show this. crashes at the same site: 11-24-48_1v2_XJJ_xbb, 14-51-29_1v1v1v1v1v1v1v1_12345687. non crashing form in 22-29-00_2v4_DESKTOPV_MoeMeed (68853), 19-21-58_2v4_Engineer_gin_HAssAN (32983), 18-56-46_1v6v1_four (16730): the outer moveAllies walk continues over the freed path and orders more allies out of the way based on the freed nodes' old contents; with freed memory poisoned the walk ends early and the replay diverges at the next CRC check. so which units get shoved in an ally jam depends on freed memory, not just whether it crashes. six of 98 long replays hit it.

[Caball009]

I think the issue description could be a bit clearer, and it'd be a good idea to include at least one replay with this bug, preferably the one that takes the least simulation time.

[Mauller]

If these are all VC6 replays, it would be good to try replicate the situation required to trigger this so it can be run in VS22.

[Caball009]

If these are all VC6 replays, it would be good to try replicate the situation required to trigger this so it can be run in VS22.

Agreed.

I gave it a try with MEMORYPOOL_DEBUG defined to overwrite memory on deallocation, but was unable to reproduce the issue so far.