Dragging a Start-menu folder onto an existing folder hangs Explorer at the Replace prompt (file op runs nested inside DoDragDrop on the taskbar thread) #2567

Describe the bug

In the Open-Shell menu, dragging a folder onto a destination that already contains a folder of the same name (i.e. a merge) hangs the conflict dialog after "Replace the files in the destination" is clicked. The dialog accepts the click, then stays frozen indefinitely. Taskbar auto-hide also stops working for the duration. Same discussion as #2492.

Individual shortcuts dragged one at a time complete normally. A folder move with no conflict completes normally. The identical merge performed in File Explorer windows completes normally.

Area of issue

Start menu

To reproduce

1. Open C:\ProgramData\Microsoft\Windows\Start Menu\Programs, and copy any subfolder up a level (or two)
2. Open the Open-Shell menu and drag the newly duplicated folder to over-write in the folder you copied it from (move).
3. At the conflict prompt, choose "Replace the files in the destination".
4. The dialog freezes. Reproduced 3/3, in both the all-users and per-user Programs trees.
5. For a workaround to release the frozen dialogue, right click the task bar and select settings. This action releases the freeze and the job is done.

Expected behavior

Replace completes and the menu returns, as it does for the same merge in File Explorer.

Open-Shell version

4.4.198

Windows version

26H2

Additional context

Been an issue for a long time now, time to give it some love!

Claude helped me with key observations, here they are:

Key observations (from a full dump of explorer.exe taken while hung):

• The whole move, including the wait at the conflict prompt, runs synchronously on the
  taskbar thread, nested inside the menu's own DoDragDrop call (StartMenuDLL is both drag
  source and drop target).
• The conflict dialog has received the Replace click; its thread is stuck making a
  synchronous COM call that the taskbar thread never services. Other threads are also
  blocked on calls into the taskbar thread.
• The taskbar thread is still pumping window messages (its context menu opens), but is not
  servicing incoming COM calls while nested there.
• "Taskbar settings" releases it; Task Manager and a plain left-click do not. Interpretation:
  launching Settings makes the taskbar thread make a COM call of its own, and COM's wait
  for that call services the queued ones.
• The same merge done in File Explorer windows completes normally, so the Windows copy
  engine and folder permissions are not the cause.

Suggested direction: run the drop's file operation asynchronously / off the taskbar thread.
Full stacks and the dump are available on request. Related: discussion #2492.