As a follow-up on what we discovered elsewhere, the problem is almost certainly down to your application having the executable stack flag set:
$ execstack -q /snap/wavebox/current/Wavebox
X /snap/wavebox/current/Wavebox
As discussed in Snap and executable stacks, when Linux encounters executables with this flag, it automatically treats requests to map files for read access as requests for read and execute access. This can fall foul of the AppArmor policies that restrict the locations of files that can be mapped as code.
Fontconfig uses mmap to load fonts and caches, but AppArmor may deny creating executable mappings depending on location (which it should: fonts are data).
Some Electron apps seem to work fine when you manually strip the executable stack flag from the binary, using something like the following:
https://github.com/snapcrafters/wordpress-desktop/commit/024661cff94c84c3a1ccd574ef51ef8405161366
Maybe give that a try for your snap? If your snapcraft.yaml actually builds the app, you’ll probably want the install scriptlet instead of prepare, and modify the executable under $SNAPCRAFT_PART_INSTALL.
As for why this happens, the toolchain only generally adds the executable stack flag if it sees code patterns that require it. So unless it is a false positive, presumably there is some code path that will malfunction without an executable stack. I’m just not sure what it is, given that most Electron apps seem to function with the flag removed.