Consider splitting archiveCache into the subfolders it visits

Use case: you have an engine with a content folder. There's lots of maps in the content folder but they're all cached in the archive cache. Then you add a new engine build and point it at the content folder as well:
```
filesystem
│
├ spring 105-1337-gabcdef
│ ├ maps/
│ │ ├ DSD
│ │ └ Tabula
│ └ archiveCache.lua
│
├ spring 105-1338-gfedcba
│ └ maps/
│ ├ DSD v2
│ └ Tabula v2
│
└ extraContent
└ maps/
├ Adansonia
├ Altored
├ ... 500 other entries
└ Zed
```

Now the newer build will spend an hour archiving the 500 maps, because it has no local cache. The request is to consider moving archive cache to the subfolders like so:

```diff
filesystem
│
├ spring 105-1337-gabcdef
│ ├ maps/
+│ │ ├ archiveCache.lua
│ │ ├ DSD
│ │ └ Tabula
-│ └ archiveCache.lua (or maybe keep as a cache of caches, idk)
│
├ spring 105-1338-gfedcba
│ └ maps/
│ ├ DSD v2
│ └ Tabula v2
│
└ extraContent
└ maps/
+ ├ archiveCache.lua
├ Adansonia
├ Altored
├ ... 500 other entries
└ Zed
```

The archive cache in the extra content folder gets created by the older engine. Now the new engine doesn't need to do anything in the content folder at all.

---

A risk is that a newer engine might want to change the format a bit, in which case local cache might be better to prevent conflicts. But I don't realistically expect any breaking changes in this area that wouldn't be better off also using a new file for this.

Start by locating the archiveCache.lua handling and the engine code that creates and consumes archive caches. Compare cache behavior across shared content subfolders and engine-specific directories, then define and validate a layout that avoids re-archiving while handling possible cache-format compatibility issues.

Written by the indexing model from the issue text.