feat: open files from later launches in the running Leafdown

[Azganoth]

Summary

Each operating-system open started its own Leafdown process. Those processes could not see each other's open documents, and whichever exited last wrote its settings and recent items over the other's. A launch while Leafdown runs now hands its arguments and working directory to the running process and exits without showing a window. The first launch behaves as before.

• tauri-plugin-single-instance is registered before every other plugin, so a second launch exits before any other plugin starts. A relative path resolves against the second launch's working directory.
• A file goes to the window that holds it under any spelling, otherwise to the most recently focused window, tracked from focus events. In both cases it opens through Open File, which activates an existing tab or adds one and reports its usual errors. A launch without a path opens a new window on the welcome screen.
• The backend keeps a queue of launched files per window, replacing the single launch path, and the frontend takes its window's queue. A visible receiving window is brought forward inside the plugin callback, while the second instance's foreground grant still holds. A window still starting up comes forward once it has shown itself and takes its queue, because showing it earlier would show it before its frontend is ready.
• The frontend listens for routed launches before its first take, so a file routed during startup is either taken then or announced afterwards. Launched files open one after another, because a newer Open File cancels one still in progress.
• Development runs (tauri dev) leave the plugin out. They share the installed application's identifier, which names the instance the plugin looks for, so a dev run would otherwise hand off to an installed Leafdown and exit. The desktop E2E build is a tauri build --debug build and routes as release builds do.
• Specification (Open From The Operating System), Architecture (backend and frontend responsibilities, Launch Workflow), Help, and the changelog describe the routing.

Related Issue

Closes #643
Refs #639

Verification

• Rust launch tests: a forwarded relative path resolves against the launch's working directory rather than the process's, and absolute, missing, and unsupported paths are kept for Open File to report. A launch without a path queues nothing but still brings its window forward, and each window's queue is taken once, in arrival order.
• Rust window and window_documents tests: focus order puts the most recently focused window first and forgets destroyed windows, and the registry finds the window holding a path under any spelling, including a pending claim.
• openSession, launchDocumentApi, and app tests:
  • routed files open as new tabs after the active one, and an already-open file activates its tab without being read;
  • an open error is reported and the next file still opens;
  • a second launch arriving mid-open waits instead of cancelling it;
  • the window listens before its first take and opens a file routed to it later.
• pnpm check passed.

Manually verified in a debug build under a separate application identifier on Windows 11, driven over the WebView2 DevTools protocol:

1. Each second launch exited with code 0 in 34–94 ms.
2. A relative path opened as a new active tab in the running window.
3. The open file, given in different letter case, activated its tab without adding one.
4. A missing file showed its error and left the tabs unchanged.
5. A launch without a path opened a second window with no tabs.
6. Two simultaneous launches both opened as tabs in the most recently focused window.

Not verified:

• the routing steps added to the launch-document desktop scenario, which CI runs;
• opening files from File Explorer in an installed build, including whether the receiving window comes to the foreground. A window opened by a launch without a path comes forward later than the launch itself, so Windows may refuse it.

Notes

• The plugin stays on 2.4.5 because 2.5 requires Tauri 2.12. 2.4.5's second instance panics on a command-line argument that is not valid Unicode and then forwards nothing; 2.5.3 fixes that.
• A file routed to a window that closes before taking it is dropped and logged.
• Folder paths and command-line options other than one file path are not routed, as Open files from File Explorer in the running Leafdown #643 scopes them out.