windows: report OS file drops to the host

[palmoni5]

Why

In visual (composition) hosting, WebViewDropTarget registers the Flutter view's only IDropTarget. Windows permits one per HWND, so a host app that wants OS file drops cannot add its own: whichever registers first wins, and a general-purpose drop package registers at plugin-registration time — before any webview exists. The webview's own RegisterDragDrop then fails with DRAGDROP_S_ALREADYREGISTERED and HTML5 drag and drop inside plugin webviews silently breaks again (the regression #5237 this target was written to fix).

What

Route file drags through the existing target instead of adding a second owner.

• Registration is decoupled from webview lifetime (acquire / releaseIfUnused), so the target can exist for a host with no webview and is torn down when neither needs it.
• New FileDropManager (channel …_filedrop): setEnabled opts in, and onFileDrop reports enter / over / leave / drop with the dragged paths (CF_HDROP) and client coordinates.
• setAccepted carries the host's answer back and drives the drag cursor, so the effect is DROPEFFECT_COPY only where the host would actually take the drop, and the plain DROPEFFECT_NONE refusal everywhere else. The answer is asynchronous and therefore lags by one drag event, which the continuous DragOver stream absorbs.

Coordinates reuse the existing two-corner mapping, so they stay correct on RTL-mirrored windows (WS_EX_LAYOUTRTL).

Security

Unchanged: files still never reach WebView2. reportFileDrag calls forwardLeave() before reporting, so a file dropped on browser UI (e.g. print preview) still cannot bypass page-level and navigation guards. With no host opted in, behaviour is byte-for-byte the previous flat refusal.

Verification

• Compiles and links in a real Flutter Windows app.
• Verified by hand on Windows: drag cursor is COPY only over the host's drop region and the X elsewhere; dropping a file delivers its path to the host; a non-matching file is refused everywhere.
• HTML5 drag and drop inside a plugin webview (draggable + dragover/drop) still works — the non-file path is untouched apart from the currentDragHasFiles_ early return, which is false for such drags.