[GBHawk + SubGBHawk] Lag Detection seems to be mostly broken

This has been an issue for a while but seems like no one has bothered to file an issue with this yet so I'm just going to put it here:

GBHawk: Lag detection doesn't really seem to work, the only frames that are ever marked as lag seem to just be frames where the LCD is off and no input gets polled at that time. If the LCD is on, GBHawk appears to just mark the frames as non-lag unconditionally, even when no input polling is happening.

SubGBHawk: All the frames are lag if they are 70224 cycles long (maximum/default), and if they are shorter they get marked as non-lag frames.

EDIT: Peeking at the code, this code looks like this may be at fault for GBHawk's lag detection issue: https://github.com/TASEmulators/BizHawk/blob/84e195659c47fdf8b617777a1504efe5cffb169e/src/BizHawk.Emulation.Cores/Consoles/Nintendo/GBHawk/GBHawk.IEmulator.cs#L143-L147

Seems like the code just marks a frame as non-lag if a new vblank is present... which doesn't really make sense on its own? And there doesn't appear to be any code to set it back as a lag frame if the joypad port isn't open (which would be a simple fix + mirror gambatte's behavior).

Start with src/BizHawk.Emulation.Cores/Consoles/Nintendo/GBHawk/GBHawk.IEmulator.cs around lines 143-147, then trace the corresponding GBHawk and SubGBHawk lag-detection paths. Reproduce the reported LCD/input and frame-length cases, and verify that both cores classify lag consistently with their input-polling behavior.