Feature request: configurable local bounds for mouseMoveMap to prevent UI collision and improve FPS usability

Hi, I am using QtScrcpy with PUBG Mobile, and the current `mouseMoveMap` behavior causes a recurring issue. ## Current behavior - Mouse movement is mapped as a continuous finger drag starting from `startPos` - The internal touch position keeps moving across a large area, effectively until it approaches the screen edges - If the in-game UI changes suddenly (death screen, skill state, entering a new match, etc.), the current touch position may end up overlapping an interactive element in the new UI - After that, mouse-look may stop working correctly until I manually reset it by switching mapping mode or using another workaround ## Important note This is not caused by `switchMap: true` buttons, and not by a bad `startPos`. The real issue is that `mouseMoveMap` has no configurable local movement bounds around `startPos`. ## Suggested feature Please add configurable bounds for `mouseMoveMap`, so the drag position is limited to a user-defined local area around `startPos` (for example, a rectangle). When the touch reaches the boundary, QtScrcpy should recenter/reset the internal touch position back to `startPos`. ### Example idea ```json "mouseMoveMap": { "type": "KMT_MOUSE_MOVE", "startPos": { "x": 0.463, "y": 0.424 }, "speedRatioX": 5, "speedRatioY": 5, "activeRect": { "leftOffset": 0.08, "rightOffset": 0.08, "topOffset": 0.10, "bottomOffset": 0.10 }, "resetMargin": 0.01, "resetMode": "RECENTER" } ``` ## Recommended behavior - Keep drag movement inside the configured bounds - When the internal touch reaches the boundary: - end the current drag - reset the internal position to `startPos` - on the next movement, start a new drag from `startPos` ## Why this helps - Prevents the touch point from drifting across the whole screen - Greatly reduces accidental overlap with newly appeared UI elements after UI transitions - Provides a generic solution without needing to detect game state or UI changes ## Important implementation note about smoothness Once configurable local bounds are added to `mouseMoveMap`, another issue may become more visible when the user chooses a very small or narrow active area. In that case, fast flick movements (for example 180° or 360° turns) may cause noticeable stutter, temporary motion loss, or even brief stops, because hard recenter/reset events would happen too frequently. A current workaround is to use higher in-game sensitivity together with lower QtScrcpy sensitivity (that is, larger `speedRatio` values), which reduces how often recentering is needed. However, this is only a workaround, does not guarantee smooth behavior, and ideally should not be required for normal use. For bounded mouse movement to feel smooth even with small active areas, the implementation should ideally: - preserve the remaining mouse delta across recenter events - process large mouse deltas in substeps, so movement continues instead of being truncated by a reset As a more advanced optional enhancement, QtScrcpy could also support a seamless alternating touch handoff using two touch slots instead of a hard stop-and-restart reset, where game behavior allows it. This would reduce dependence on sensitivity-tuning workarounds, improve out-of-the-box usability, and lower the learning curve for users. This would significantly improve FPS game usability. Thanks!