[v2] fix: Files DragAndDrop bugs with OnDomReady and DisableWebViewDrop

[leaanthony]

Summary

Fixes #3563

This PR addresses two critical issues with file drag-and-drop functionality:

1. OnDomReady triggering on every drag-and-drop: When EnableFileDrop: true, dropping files would trigger OnDomReady multiple times because the browser's default behavior (navigating to the dropped file) wasn't prevented early enough.

2. EnableFileDrop + DisableWebViewDrop conflict: When both options were enabled together on Windows, file dropping stopped working entirely.

Root Cause

• JavaScript drag/drop event handlers that call e.preventDefault() were only registered when the user called runtime.OnFileDrop()
• There's a timing gap between page load and when OnFileDrop() is called (typically in the OnDomReady handler)
• During this gap, if a file is dropped, the browser's default behavior kicks in - navigating to the dropped file (file:///path/to/file.txt)
• This navigation triggers OnDomReady again

The Fix

1. Early handler registration (JavaScript)

• Added setup() function in draganddrop.js that registers drag/drop handlers immediately
• Called from main.js during runtime initialization (before runtime:ready)
• Handlers prevent default for file drops even before the user registers a callback
• Runs on every DOM load to ensure handlers are always registered

2. Windows AllowExternalDrag fix

• Only disable AllowExternalDrag when DisableWebViewDrop: true AND EnableFileDrop: false
• When both are true, drag events need to flow to JavaScript

Test plan

• [ ] Test drag-and-drop with EnableFileDrop: true - verify OnDomReady only fires once
• [ ] Test with both EnableFileDrop: true and DisableWebViewDrop: true on Windows
• [ ] Test on Linux and macOS to ensure no regressions
• [ ] Verify file drop callbacks still work correctly

🤖 Generated with Claude Code