Take file drops on Linux in the shell, where the WebView cannot see them

[thcp]

Closes #672

What was wrong

On the Linux desktop app, dropping a file anywhere turned the window into a bare media player. Dropping it on the URL box typed its file:// path into the box, and Process then failed with "URL must use http or https".

Both have one cause. WebKitGTK, the Linux webview, reports a drag from a file manager as text/uri-list and text/html, never as Files. The drop guard from #612 looks for Files, so it never recognised the drag, and WebKit's default ran instead: open the file, or type its path into a text box. Windows, macOS and Chromium all report Files, which is why the guard works there.

Widening the guard would not have fixed it. I measured it against a real drag into WebKitGTK 2.52. Even with the drop cancelled, the page receives no files and the path is blanked out. The page can stop the navigation but can never get the file.

The fix

On Linux the app takes the drop, not the page.

• The main window's native drop handler is on for Linux only. Tauri consumes the drop before WebKit's default can run.
• wry only claims drags that carry files, so the library's own drags between folders, lanes and the trash are untouched.
• That was the reason the handler is off everywhere (fix(ui): fix drag-and-drop on Windows and catalog rail layout #24): on Windows it stops the page's own drags. It stays off on Windows and macOS.

The window is now built in setup from its existing tauri.conf.json entry, marked "create": false, with only that one setting changed per platform. A per-platform config file would have needed a second full copy of the window definition.

No command takes a file path from JavaScript. The page is a remote origin to Tauri, and dragout and download_to_path already follow this rule for that reason.

• A drop is recorded against opaque ids, and the page is told only a name and size for each.
• The page can read back a file the user dropped, once, by id, from the latest drop only.
• Reads are capped at the upload limit.

The page waits on a command, not an event. A remote origin cannot listen to Tauri events without a capability that would expose every core event command. Signals are kept in a log that each caller reads from its own position, so a reloaded page's leftover call cannot swallow the next drop.

On the page, applyFiles is split into screening and staging.

• A native drop is screened on names and sizes first, so files that will be refused are never read.
• From there it follows the same path as the file picker, with the same messages.
• A file that has disappeared before it is read is reported by name, in all ten languages.

The upload limit now appears in three languages, and a new test holds the server, the page and the app to the same number.

Verification

• A real Tauri 2.11 app on Linux, built around this module, with genuine drags from a separate GTK process:
  • a drop on the page and a drop on a text box both arrive with the file's real bytes;
  • nothing navigates, and nothing is typed into the box;
  • reading the same file a second time is refused;
  • a drag using the library's own data types still lands on its target.
• The Windows build still opens its main window.
• Tests:
  • e2e: 238 pass, 9 new, covering the page's side against a stand-in app.
  • Rust: 110 tests pass on Windows and 120 on Linux, 11 of them new. fmt and clippy are clean on both.
  • i18n coverage is clean.
• macOS could not be compiled locally, so PR CI covers it.