fix(macos): let WKWebView handle file drops natively

[LILQK]

Dragging a Finder file onto an open WhatsApp conversation can do nothing on macOS: Tauri consumes the native drop, then the streaming bridge tries to locate WhatsApp's attachment controls. A QUEUED:1 acknowledgement only confirms that the page received the bytes; if those controls cannot be found, no attachment preview opens and the failure remains silent.

Disable Tauri's drag-drop handler on macOS so WKWebView delivers the original drag events and files directly to WhatsApp's drop zone. This uses the same native-drop approach already enabled on Windows and avoids depending on WhatsApp's changing attachment-menu selectors. Update the comments and README to describe the platform-specific paths and Linux-only streaming limits.

Validation on macOS 26 / Apple Silicon:

• Built the release .app bundle with Tauri CLI.
• cargo test --locked --release --manifest-path src-tauri/Cargo.toml — 96 tests passed.
• node src-tauri/resources/bridge.test.mjs — passed.
• node settings-ui/comboToAccelerator.test.mjs — passed.
• node settings-ui/dialog.test.mjs — passed.
• Reproduced the bridge failure with unavailable attachment inputs: QUEUED:1, zero attachments, and no failure notification.

Manual validation still needed: drag a file from Finder onto an open, logged-in WhatsApp conversation and confirm that the attachment preview appears. The build and unit tests do not verify that end-to-end flow.

[karem505]

Thanks for this, @LILQK, and for the clear write-up of the silent QUEUED:1 failure. Handing drops to WKWebView matches what #31 did for Windows, and the diff is clean.

Before merging, two things need a real Mac, as you noted:

1. The main path: drag a file from Finder onto an open, logged-in conversation, and check that WhatsApp's attachment preview appears. Please try one image and one document if you can.
2. Promised files: this removes the README note about Photos.app and the in-app hint for drags that only "promise" a file, such as an image dragged straight out of Photos or a browser. With the native path, does such a drop now attach, or does it silently do nothing? If it's silent, we should keep a line in the README saying to drag from Finder or use the attach button.

Also, CI hasn't run here yet: workflows on PRs from forks wait for maintainer approval.

---

Generated by Claude Code

[LILQK]

Thanks @karem505! Tested on macOS 26 / Apple Silicon with the release build:

1. Finder drops: dragging an image and a document from Finder onto an open, logged-in conversation both open WhatsApp's attachment preview as expected.
2. Promised files: dropping an image dragged straight out of Photos (and from a browser) also attaches correctly with the native WKWebView path, so the old README note and in-app hint are no longer needed.

Ready for CI whenever you can approve the workflows.

[karem505]

Thanks for testing, @LILQK. That's exactly what was needed, and good news that drags out of Photos now attach too. Once the CI workflows are approved and green, this is ready to merge.

---

Generated by Claude Code