200 MB/s wgpu memory leak (DPI scaling/multiple monitors/resizing)

Describe the bug

Very bad memory leak. Like 200mb/s of memory leaking type of memory leak. While the leak is ongoing, any element of the interface is inaccessible--no updates to checkboxes or text fields or whathaveyou will appear. The mouse cursor will still adjust as it's been hovered over them, and the memory leak accelerates when a repaint is requested (I've included such a line in my example but you can remove it and still get it to happen)

To Reproduce
I have three monitors arranged in this configuration

1 is 2560x1080 with scaling at 100%
2 is 3840x2160 with scaling at 150%
3 is 1920x1080 with scaling at 100%

Getting this to happen is a bit finicky.
In my non-minimal example, all that really needs to happen is the window is created in a boundary between two or more monitors, and then I drag it from that boundary anywhere else, and then we start leaking about 200mb/s of memory. Very bad! Sometimes it stops leaking when I drag it fully to a monitor at 100% scaling, sometimes it doesn't.

I've created a minimal example (literally just the app demo with a side panel that updates some values in a struct), but it's significantly less inclined to letting the bug occur.
eguimemleak.zip
Sometimes it's enough to position the window at the boundary between all three monitors and start messing with the dragvalues, and the interface will freeze up and leak memory as long as you continue dragging. This doesn't always work for me, but it works often enough that it may be worth examining, as the code is far more tractable. Uncommenting the repaint request at the bottom makes the bug more inclined to occur.

Expected behavior
No memory leak

Screenshots
here is the memory footprint of the glorified app demo contained in the attached zip:

and of the actual project after a roughly equivalent time leaking (maybe 20s):

Desktop (please complete the following information):

• Windows 10

Start by running the attached eguimemleak.zip example on Windows 10, placing the window across the described monitors, dragging it between scaling boundaries, and testing the optional repaint request. Compare the minimal example with the linked IFSRS reproduction while observing memory growth and UI freezing. Done means the boundary/resizing sequence no longer leaks memory and the interface remains responsive.