Drag and drop does nothing when the app runs as administrator

[rodrifelix99]

Reported by the same user as the mods-folder permission issue: with the
app running as administrator, dragging files onto the window does
nothing at all.

This is Windows UIPI. Explorer runs at medium integrity, an elevated app
runs at high, and the shell will not hand a drag from the lower process
to the higher one. desktop_drop calls RegisterDragDrop and never sees
the drop, so the app has no idea anything happened.

The fix is the documented one: call ChangeWindowMessageFilterEx for
WM_DROPFILES, WM_COPYDATA and WM_COPYGLOBALDATA (0x0049) on the
window that owns the drop target. That is the top-level runner window
plus the Flutter view's child HWND, both reachable from
FlutterWindow::OnCreate.

Costs nothing when the app is not elevated, so it can be unconditional.

[rodrifelix99]

Fixed in c82cf1b. The three messages OLE drag and drop rides on are let through the UIPI filter, on the top-level window and on the Flutter view. Compiles on the Windows CI runner; still worth a try on a real elevated run.

[rodrifelix99]

Reopening: the fix in c82cf1b does not work. It was never run elevated, only compiled, and having now tested it on Windows 11 the drag is still refused.

Same build, same file, dragged from the desktop:

• launched normally, the drop works and the file installs
• launched as administrator, the cursor shows the no-drop symbol and nothing happens

I instrumented the runner to find out why, and the three message filters are not the problem. In the elevated run all six ChangeWindowMessageFilterEx calls return success with GetLastError 0 (both the top-level window and the Flutter view), and OLE's drop target is registered on the view, which is the window desktop_drop registers on:

integrity: HIGH (elevated)
top WM_DROPFILES: ALLOWED (GetLastError=0)
top WM_COPYDATA: ALLOWED (GetLastError=0)
top WM_COPYGLOBALDATA: ALLOWED (GetLastError=0)
view WM_DROPFILES: ALLOWED (GetLastError=0)
view WM_COPYDATA: ALLOWED (GetLastError=0)
view WM_COPYGLOBALDATA: ALLOWED (GetLastError=0)
after RegisterPlugins: drop target on top=no, on view=YES

So everything the fix was supposed to arrange is in place and the drop is still refused. The reason is that desktop_drop uses OLE drag and drop, not WM_DROPFILES. RegisterDragDrop marshals an IDropTarget and Explorer calls into it over COM, so what has to be allowed is a medium integrity process calling into a high integrity COM server. Letting those three window messages through does nothing about that. The trio is the right fix for the DragAcceptFiles/WM_DROPFILES path, which is not the path this app is on.

That makes the comment in flutter_window.cpp wrong as well, and the note in docs about what the hand-edit buys us.

Where to go from here, roughly in order of how much I believe in them:

1. Say so in the app. The Install button uses an in-process file dialog and works fine elevated, so the app can detect that it is running at high integrity and put a line on the library telling people drag and drop will not work in this mode and to use Install. Honest, small, and it beats a dead window with no explanation.
2. Do not need elevation in the first place. The reason people run it as administrator is the games that keep mods under Program Files. Writing those through a helper that elevates only for the copy would remove the whole problem, and the read-only banner already knows when the folder cannot be written to.
3. Try to make the COM call itself legal, with CoInitializeSecurity and a permissive descriptor plus a lower mandatory label on the process. I have not got this working and I am not sure it is worth the surface area for a case that option 1 covers honestly.

Leaving c82cf1b in place for now since it is harmless, but it should not be described as fixing this.

[rodrifelix99]

Landed on dev in 14fd5f8, though not a fix, so leaving this open.

The app now checks whether it has administrator rights at startup and, when it does, banners the library to say drag and drop will not work and to use the Install button instead. Install is unaffected: the file picker runs in-process, so nothing about it crosses an integrity boundary. Confirmed on an elevated run, banner shows.

That only fixes the silence. Dragging a file onto the window still does nothing when elevated, and nothing in this commit changes that, which is why the issue stays open rather than being closed as done.

The message filters in the runner are still there. They cost nothing and they are the right thing for the WM_DROPFILES path, but the comment on them now says what was measured instead of claiming they solve this.

What is left, if it is ever worth it: make the COM call itself legal, with CoInitializeSecurity and a permissive descriptor plus a lower mandatory label on the process, so a medium integrity Explorer can reach a high integrity drop target. I have not got that working and it is a fair amount of surface area for a case the banner now covers honestly. The other way out is to stop needing elevation at all, by writing the Program Files games through a helper that elevates only for the copy, which would retire this whole problem rather than work around it.