MacOS: Game mishandles clicks if unpaused while the mouse isn't over the window

[Macil]

If you're playing on MacOS in windowed mode with the game paused (menu or console open) so the mouse is visible, and then you unpause the game while the mouse is outside of the game window, then your mouse will disappear and you can look around as normal, but the next time you click, the game will lose focus. This also happens if you cmd-tab to an unpaused game while your mouse isn't over where the game window is. It seems the game isn't completely capturing the mouse properly.

You can even trigger this issue even just by pausing and unpausing depending on where your cursor appears: the mouse usually appears over the game window when you open a menu, but if you look down and to the right or left and then pause, the mouse may reappear beyond the rounded corner of the window and then trigger this issue when you unpause.

The issue is weirder if you unpause the game while it's over the game window's titlebar or over the MacOS system menu. The mouse can become frozen or invisible even after you pause the game again, staying broken until you close the game.

This issue exists in QuakeSpasm-Spiked and vkQuake too but worse. Both of those ports make the window resizable and it seems like this issue interacts badly with that feature: if you unpause the game with your mouse at the window border -- which can easily happen frequently, because if you last looked far to the left or right when you open the escape menu, the mouse will be positioned exactly on the window border -- then the game will actually freeze whenever you're holding the mouse down until you let go of it, and the issue doesn't go away until you pause the game again and unpause with the mouse not at the window border.

[sezero]

@ericwa, @andrei-drexler ?

[Macil]

This looks related to Aleph-One-Marathon/alephone#398 / libsdl-org/SDL#6994, except not fullscreen related. They're working around it by centering the mouse prior to grabbing it: Aleph-One-Marathon/alephone@e297bd3. Not sure if there's an SDL bug making this necessary or if this is supposed to be necessary.

I've submitted a PR which works around this issue the same way by centering the mouse right before grabbing it: #49.