fix: make drag-and-drop work on Linux (capture-and-inject) — v0.4.1

[karem505]

Problem

v0.4.0 added drag-and-drop by disabling Tauri's drag-drop handler and relying on the webview delivering the OS file drop to the page as an HTML5 drop. On Linux/webkit2gtk that never happens — broken on Wayland, and on X11 the GTK drop is accepted (the + cursor shows) but it still never reaches web.whatsapp.com's DOM. Result: dropping a file did nothing.

Fix — capture-and-inject

Keep Tauri's drag-drop handler enabled and:

1. Capture in Rust (WindowEvent::DragDrop) — this works at the GTK level on both Wayland and X11 (the part that was working all along).
2. Read the file off the UI thread, base64 it, and eval an injection into the page.
3. bridge.js __whatrustHandleDrop rebuilds the File and feeds it to WhatsApp's own attach flow:
   • Primary: set a hidden <input type=file>'s .files + fire change (React fires onChange for synthetic events; isTrusted is not checked).
   • Fallback: synthetic drop via a plain Event with dataTransfer defined through Object.defineProperty — because new DragEvent('drop',{dataTransfer}) silently nulls dataTransfer in WebKit.
   • WhatsApp opens a preview/Send composer (never auto-sends), so trying both is safe.

No GDK_BACKEND=x11 forcing needed — works Wayland-native.

Verification

• ✅ Verified end-to-end on real WhatsApp Web — Wayland and X11, with an image (PNG) and a document (.sh); the media composer opened both times.
• ✅ Injection mechanics confirmed in real webkit2gtk 2.52 via a PyGObject harness (File-from-base64, DataTransfer, input.files+change, and the defineProperty drop all deliver the file).
• ✅ cargo build --locked + cargo test --locked → 51/51 (incl. RFC 4648 base64 vectors). CI covers Windows + macOS.
• Boundary diagnostics now go to the existing file log (new JS-callable dlog command) so future DnD issues can be traced without a console.

Releases as v0.4.1.

🤖 Generated with Claude Code