Looks okay I think although I find the seat locking again a bit overkill. I don't really see a scenario where a wine process would be used across seats, can this really happen on Wayland?
I understand that as the event is dynamically sent we may have to support it, but I would find it simpler if we could assume that we have a seat from the start (eventually waiting for it on startup, idk), and where we'd just abort if the seat is removed.
Probably the most interesting scenario for dynamic seat management is remote access (e.g, VNC/RDP). This is typically implemented by the compositor by exposing a separate `wl_seat` for each viewer/connection. When the remote viewer is closed, the compositor destroys the associated `wl_seat`, so Wayland clients should ideally be able to gracefully handle such removals.
Proper/full remote support (e.g., multiple viewers and/or non-headless setups) would require multi-seat handling, which we don't currently implement in the driver.