Grab and Move low quality

### Description of the new feature / enhancement

## Grab and Move feels unfinished and has easily avoidable issues

It should use `DwmGetWindowAttribute(hwnd, DWMWA_EXTENDED_FRAME_BOUNDS, ...)`, otherwise the overlay
can be offset from the actual visible window.

2. **The real window moves constantly while dragging**

Moving a window nativly is far more efficient than actual `SetWindowPos` calls, since DWM just composits the window to the correct position, there are no WM_MOVE or other events, only the final "release" when dragging a window actually sends that event which is far more efficient.

Also i'd assume the whole point of the overlay is to show where the window will be, so if you move window 60 times per second might aswell get rid of the overlay.

https://github.com/user-attachments/assets/dea9d0f3-9b38-4d39-b415-953ab1c0e402

Other program used:
https://github.com/ThrowTop/hyprwin

3. **60hz hardcoded**

`if (now - g_lastMoveTick >= THROTTLE_INTERVAL_MS)`

limiting updates to 60hz is really ugly on high hz monitors, but doing `SetWindowPos` more than 60 times per second is also a bad idea.

Should probably just use the overlay and move the window once its done.

4. **Resize direction can change mid-drag**

In the video above i only resize and move my mouse, if i move mouse fast enough or past the window itself it just recalculates the anchor point and starts resizing in a different direction, feels very weird, each resize session should probably just store the direction at start and only use that until its done.

5. **Preview ignores min/max window size**

The overlay shows preview sizes the window wont actually allow.

Use `WM_GETMINMAXINFO` and clamp the overlay to match the bounds instead of hardcoding
```cpp
static const int MIN_WINDOW_WIDTH = 150;
static const int MIN_WINDOW_HEIGHT = 50;
```

6. **Overlay looks like a debug rectangle**

The current overlay is basically a big semi-transparent white box. It looks unfinished and does not fit Windows 11.

At minimum it should be a proper outline using the real visual bounds, with rounded corners instead of a filled rectangle.

### Expected behavior

* Overlay matches the actual visible DWM window bounds.
* Real window is moved/resized once on mouse-up, not constantly during drag.
* Preview feels smooth on high refresh displays.
* Resize edge/corner is locked per session.
* Preview respects the target window’s min/max size.
* Overlay looks like an actual UI feature, not a debug placeholder.

As its an official microsoft open source project I dont understand how this feature made it into powertoys.

### Scenario when this would be used?

So its an actually usable feature.

### Supporting information

Locate the Grab and Move implementation and trace its use of DwmGetWindowAttribute, SetWindowPos, the throttle interval, resize anchoring, and the overlay size limits. Compare the current behavior with the stated expected behavior, then verify that bounds, deferred movement, refresh handling, resize direction, min/max sizing, and overlay styling all work together during dragging.

Written by the indexing model from the issue text.