Fix bug where 'archive' XMB files could end up being written to the user mod

Users sometimes ended up with bad (wrong version) XMB files in the user mod. This resulted in A25 loading a black screen.
There is a combination of unfortunate code paths that lead to this. The core issue is that:

• rP25375 changed the XMB loading code that if there is an error in Init from a cached XMB, it reports an error. This error happens to be silent, because the GUI expects CXeromyces to do its own error reporting (a pretty poor decision, all in all, but whatever). This explained why the black screen showed no errors.
• The code flow attemps to load an 'archive' XMB first, then only a loose cache. _But_ if the XMB that fails to load is an archive (which generally never happens except when using incompatible mods, which is generally less easy in A25 since we added code to stop that), then the game will try to recreate the XMB as an 'archived' path, not a 'loose cache' path as it would usually do.
• Because the 'archived' path already exists in the VFS, the game will attempt to overwrite that. It so happens that in non-dev copies, this writes to the user mod.
• Because the user-mod is always loaded, this was unexpected for users.

Fixing this is rather simple: the game should never attempt to write 'archive' XMBs in that function. Added explicit barrier, which shouldn't matter performance-wise but fixes the issue by writing in the proper place, and also properly recovering in case of read failure.
I will note that the game will still try to load the archived file, and recreate it every time, but I don't think that's a particularly big deal, in general having engine-incompatible mods in the future should be harder because of A25 changes there.
(NB: users that have used both A24 and A25 should perhaps still be advised to check their user mod folder, otherwise they'll end up recreating those files forever).

Reported by: dave_k

Fixes #6320

Differential Revision: https://code.wildfiregames.com/D4275