user32:Unify drop_target cleanup at end of drag_drop_drop to avoid spurious DragLeave in next DnD session Change-Id: I1213239a7c7981c4d3f7cb56281e3687527c7885 Bug: drag_drop_drop calls IDropTarget_Drop but fails to Release+NULL drop_target. When the next XdndEnter arrives, drag_drop_enter releases the old data_object, whose destructor sees the stale drop_target is non-NULL,incorrectly calls IDropTarget_DragLeave, and interrupts the new drag session. Fix: Remove Release+NULL from the else-if branch, add a single Release+NULL after if (drop_file) as the sole cleanup point, avoiding double-release. Cannot reproduce in Wine tests: DoDragDrop API bypasses clipboard.c entirely and has no stale pointer issue; the X11 DnD path requires cross-process COM deferred Release timing, which cannot be simulated in a simple Wine test case. MSDN:https://learn.microsoft.com/en-us/windows/win32/api/oleidl/nf-oleidl-idropta... [drop_receiver.exe](/uploads/85f0571bc354238576bf9e50a62f12e2/drop_receiver.exe) [drop_receiver.c](/uploads/b409b8a12a352dae9dbd4dab5fa322d2/drop_receiver.c) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11107