WaylandBackend: re-arm the forced pointer lock when focus returns

[vincent562]

Problem

With --force-grab-cursor, the cursor is confined to the game correctly at first, but as soon as focus leaves the gamescope window (alt-tab, workspace switch) and comes back, the confinement is gone for good: the cursor moves freely out of the game and onto other monitors. Clicking back into the window does not restore it.

Reproduced on GNOME 50 / Mutter, Wayland session, 3 monitors, NVIDIA 595.84. The same symptom is reported under Hyprland in #1285.

Cause

With --force-grab-cursor, g_bForceRelativeMouse arms the lock exactly once, from CWaylandConnector::Init(). The per-frame call to SetRelativeMouseMode in steamcompmgr that would otherwise keep it in sync is explicitly gated behind !g_bForceRelativeMouse, so it never runs in this mode.

When the host compositor deactivates our LIFETIME_PERSISTENT constraint on focus loss and does not reactivate it, nothing ever re-arms it: SetRelativeMouseMode's guard only compares bRelative against m_pLockedPointer, which is still non-null. Wayland_LockedPointer_Unlocked just clears m_bPointerLocked and leaves the object in place.

Fix

Track the host-side unlock in m_bPointerUnlockedByHost, allow SetRelativeMouseMode to recreate the constraint when that flag is set, and re-arm from the keyboard and pointer enter handlers — i.e. when focus actually comes back. Both handlers are used because the order of the two events is not guaranteed; the flag is cleared on re-arm, so the constraint is recreated once per unlock rather than per event.

Testing

Built and run against wlroots 0.19.2 (the Ubuntu 26.04 system library) and the vendored 0.20.2 on master. With the patch, confinement survives repeated alt-tabs and workspace switches, and the cursor stays visible and usable in game menus. Verified in a Proton game over XWayland and with a plain X11 client.

Behaviour without --force-grab-cursor is unchanged: ReArmForcedPointerLock() returns immediately unless g_bForceRelativeMouse is set.