[Feature]: Implement WebSocket Backpressure Handling & Movement Throttling

[PinJinx]

Problem Statement

Currently, movement events are sent to the server on every touch event. On some devices, it is like 60–120 WebSocket messages per second. While this will work under ideal network conditions, it can cause issues:

• The Wi-Fi connection is unstable or slow
• The device moves to the edge of network range
• There is temporary packet delay or congestion
  It best to handle all these traffic and not overwhelm the server and floods the network.

Proposed Solution

Instead of sending a movement packet on every touch event:

• Accumulate dx and dy deltas
• Send a single movement packet per animation frame.
• Basically Cap movement updates to ~60Hz

Before sending movement messages:

• Check bufferedAmount and if there is a lot of packets unsynced because of which If it exceeds a defined threshold, drop older movement events temporarily and Continue allowing critical events (click, key, combo).

Alternatives Considered

Only preventing packet build up

• This would prevent extreme queue buildup but would not reduce packet frequency during normal operation.

Server-side rate limiting

• This would still allow client-side flooding and only shift the problem downstream.

Additional Context

• I noticed this while i was downloading a game with rein in background. Adding a rate limiting and managing the packets. I think can fix a lot of the laggy behavior. It may also help some of the other issues i have seen like zombie state and desynchronization in Wayland.

Checklist

• I have searched for existing feature requests to avoid duplicates

[PinJinx]

@imxade If you feel this is a valid feature that is needed for the project. Could you assign it to me I am happy to help.