[BUG] Game does not start when the total number of missions above 64

Windows Version Number: Windows 11 24H2
App Version: 3.31.595856

I am building a mission campaign as a mod for Escalation, and I ran into a hard ceiling:
the game stops starting as soon as the total number of missions in the install goes above
64. Support asked me to bring this from a ticket to the forum, so here is everything I
have, together with a small mod that shows the crash in about a minute.

Has it ever worked: the game itself works fine and always has. The crash shows up only
when the mission count crosses 64 (55 vanila + 9 mod), and it shows up every time it crosses it.

What the error looks like: there is no error. No window, no message, no crash dialog from
Windows. The process starts, works for a second or two and disappears. In RunLog.txt the
last line is written while the game is building its list of missions, and nothing follows
it.

Version: 3.31.595856 from Steam. It happens with AshesEscalation_DX11.exe and with
AshesEscalation_DX12.exe.

Hardware: i9-13900k, 128 GB DDR5, RTX 2070, Windows 11 24H2

How to see it. Attachment [1], MissionLimitTest.zip, is a mod I made for this. It has ten
empty scenarios in it, they run on stock maps and contain nothing but a header, two
players and one empty trigger.

1. Verify the game files in Steam first, so that a damaged install cannot be the
explanation.
2. Unpack attachment [1] and put the MissionLimitTest folder into the Mods folder, so that
you get Mods/MissionLimitTest/index.ashesmod.
3. Start the game. It disappears without a message. The total is now 65.
4. Delete any one of the ten files in MissionLimitTest/Scenario and start the game again.
It comes up normally and lists the nine that are left. The total is 64 again.

The files are identical in step 3 and step 4, and the only difference is how many there
are. If the forum does not let me attach the archive, you can build the same thing in two
minutes: make a mod folder with an index.ashesmod and a Scenario folder in it, and copy
ten of the stock scenario files from the game's own Scenario folder into it under new file
names. Those files already have their own text keys, so nothing else has to be edited.

Why 64 is not a lot: a stock install already uses 55 of those slots, 31 campaign missions
(Episode1 has 13, Episode2 9, Episode3 6, Episode15 3) and 24 scenarios. That leaves nine
for a mod, and the tenth one stops the game from starting.

What exactly is counted. Two patterns are enumerated, for the game folder and for every
mod folder, and added up together:

<root>/Scenario/*.xml
<root>/Campaign/<episode>/*.xml

It makes no difference whether the files sit in a mod or in the game folder, whether they
are scenarios or campaign missions, or whether they are spread over one mod or several.
The contents make no difference either, because the counting happens while the folders are
listed, before any file is read. A leftover xml from editing costs a slot exactly like a
finished mission does.

Where it goes wrong. The offsets below are from AshesEscalation_DX12.exe with image base
0x140000000, and the full write-up is attachment [2], mission_limit_analysis.txt. The
enumeration is the function at 0x140097400. It fills one record per mission, records are
0x590 bytes, and the running index is never compared against the capacity of the array,
which is 64 records. The same code shape appears twice, at 0x1400979b3 for campaign
missions and at 0x140097bfb for scenarios.

The crash itself lands in the string hashing routine at 0x1404156E0, which is
AshesEscalation_DX11.exe+0x408AF0, with exception 0xC0000005 on a read of
0xFFFFFFFFFFFFFFFF. Mission strings are kept as a descriptor of pointer, length and a
precomputed hash, so for mission 65 that descriptor is read back out of memory that is
past the end of the array and belongs to something else. In the dump there are exactly 64
records at a stride of 0x590, and the 65th file in alphabetical order has no record at
all. I also kept the minidump, 13 MB compressed, and can upload it if anyone wants to look at it.

What would help. Raising the capacity would solve it for us. If that is not practical,
comparing the index against the capacity and writing the names of the files that did not
fit into RunLog.txt would at least turn a silent crash into something a mod author can act
on. Right now the only hint is that the game worked yesterday and does not work today.

Attachments ([1]MissionLimitTest.zip, [2] mission_limit_analysis.txt)