Troublesome GBA game and I did not know about it?
Must be slipping.
This might also be something you care to draw the attention of https://mgba.io/tag/debugging/
(the analysis of the Shrek videos being fascinating reading) or one of the emulator authors (in addition to mgba noted there then not sure what vba-m is doing these days but they were carrying the torch of vba, no$gba is still updated too). Do also try it on those in case it was just some ancient crusty version of VBA that the DRM worked in where the more accurate options of the other stuff mentioned works fine. I would still try to figure out what it is to nerf it in case of another issue though.
I don't even want to speculate on what goes here -- these sorts of one off devs having some fun things are usually where the exotic DRM types click in. You have an example of the various known methods in the one above but this could be anything from save timing (saw that as one of the rarer types on the DS, probably only months after this and such things are popular all over the shop), some quirk of hardware timing, some quirk of emulator access (does an emulator accept a read/write to an area that does something else than was is intended -- what is technically invalid below 8000h on the DS being a good example of that), save type fun (most flash carts, though not a lot of modern emulators, will do fun things there depending upon what it detects vs what reality says), trimmed ROM detection (unlikely here but has been a problem for some flash cart users in the past), save fun (could embed some kind of check in the save, we did see something similar on the DS for one of the music games that allowed you to download songs and if this has a PC running in the background...). Hopefully failed AP checks are immediate upon failing the check (not some obfuscated check that sets a result that is acted upon several thousand cycles later) and obvious (no subtle can't win the game/will only have boring encounters type deal) such that you have something to latch onto.