Some modifiers, notably LevelThree, were not accounted for in the
modifier mask calculation. This leads to an incorrect keymap where some
key symbols were listed for keys without (or insufficient) modifiers.
Emulating those keys can then produce the wrong keysyms.
Reproducible with server and client on English(UK) layout and typing
e.g. [. That key has its own key AD11 (right of P) but is also on
the third level of AE08 (the 8 key). When the server sends the keyid 91
(for [) the client looks it up in the pre-generated keymap. It is found
first on the 8 key with no modifiers (because LevelThree was previously
ignored), hence the client simulates a key 8 press without modifiers.
This erroneously produced an 8 instead of the wanted [.
Fix this by ensuring that all modifiers are accounted for in the key
map. This fix is likely incomplete as it does not account for the full
virtual modifier to real modifier mappings possible (e.g. Mod5 *may* be
something other than AltGr) but it does push the can a bit further down
the road, for someone else to release the worms.
Closes: #8168
For the longest time, this log line has bugged me:
```
active sides: e
```
It's hex, but it looks like a bug, since there's no `0x` prefix. Also, most humans can't read hex, so I added a string representation.
New version:
```
[2025-08-06T11:56:00] DEBUG: active sides: LRT (0x0e)
```
Previously we were toggling the 'MouseKeys' Windows accessibility feature on and off, but this was causing many bugs; cursor show delay while Windows brings up the mouse stack(?) and often forever lost mouse cursor when toggling off the 'MouseKeys' feature. After a few days of hacking away at this, it seems safest to just leave it on.
The `ShowCursor` function does not directly show/hide the cursor; it increments or decrements the internal display counter. When that counter reaches a certain positive/negative number, then the cursor is shown or hidden at a particular threshold.
