The logs in my original message are from devmode. In devmode, the fonts load correctly. In strict mode, the fonts don’t show. However, all other desktop snaps use those fonts, even those not using the desktop helpers or any extension. If I run snap run --shell photoscape, I can access and memory map those fonts from a python shell.
I am also curious as to how these fonts work. They are not using a layout, and when I change the fonts on my host system, the changes are not shown in /usr/share/fonts. I assume this is an implementation of @jamesh’s proposal here: Desktop: allow access to host system fonts
At the moment I have tried wine and wine64, both from the archives, from winehq and from the wine-platform-5-stable snap. They all show the same behavior:
With vanilla wine, the snap can memory map the fonts in strict mode. However, if I run the application after I install the gdiplus.dll library from Microsoft, memory maps are denied by apparmor. Other Microsoft libraries don’t seem to have that problem, it’s only happening with gdiplus.dll from what I’ve tested.
This seems to point in the direction that somehow gdiplus.dll turns on the READ_IMPLIES_X personality bit of the wine process, but I can’t really test that theory because I didn’t find a way to see the personality bits of a running process. (Are personality bits a Linux thing? Are they an apparmor thing? I couldn’t find much documentation about personality bits.)
Given that gdiplus.dll is not an elf binary, I also can’t test if it has the executable-stack flag. I don’t know if Windows binaries even have executable-stack flags. 
I understand that this might be going too deep into Wine territory, but I’m hoping I can at least find a way to conclusively say the READ_IMPLIES_X personality is the issue, what sets that personality and why, so I know what to ask the Wine devs. Given that many wine applications require gdiplus.dll from Microsoft, I’d like to investigate this further and see if we can fix it somehow…