fix(desktop): restore unreachable windows and avoid Windows recovery deadlocks

[lingcang728]

Why

A Windows user reports that ZeppBridge initially worked, but subsequent launches leave a tray icon and no accessible app window, including after reinstalling v2.1.2 and v2.2.0. The supplied log reaches background normalizer replay, which confirms database initialization succeeded on those launches. It contains no monitor-sizing, window-open, or fatal-startup diagnostics.

The existing code has a confirmed recovery defect: when main is absent, tray and single-instance callbacks build a WebView synchronously. Tauri explicitly documents a Windows deadlock for window creation in synchronous event handlers: https://docs.rs/tauri/2.11.5/tauri/webview/struct.WebviewWindowBuilder.html. Existing-window recovery also ignores window API failures and never repairs off-screen geometry. current_monitor() returning None or an error produces no log at all.

The supplied log does not prove which path caused this user's original failure. In particular, neither a zero-sized monitor nor a WebView crash is established. This PR fixes the concrete recovery defects and fills the diagnostic gaps needed to verify the affected machine. No private logs or account data are included.

Changes

• Run tray, repeated-launch, and startup window restoration on a worker. Coalesce concurrent requests with a guard that releases on failure, and defer early second-instance requests until setup is ready.
• Find the main-window config by label when rebuilding. Apply the global close-to-tray handler to rebuilt windows too.
• Fall back from an unavailable current monitor to a usable primary/available monitor. Move inaccessible windows back into a physical work area, handling negative monitor origins and oversized high-DPI windows while preserving reachable geometry during normal reopening and leaving intentional fullscreen geometry to the window manager.
• Record startup stages, main-page load events, missing windows, monitor failures, open requests, and resulting visibility/geometry. Log native-operation errors and runtime panics instead of losing them in Windows release builds.
• Retain existing minimum-size checks and correct a nearby comment that presented an unverified cause as confirmed.

Validation

• Passed locally: production frontend build (npm run build), workspace Rust formatting, git diff --check, and seven executable Rust geometry tests (disconnected displays, negative origins, inaccessible titlebars, normal/maximized windows, zero/tiny sizes, oversized windows, and overflow boundaries).
• Also passed locally: two concurrency/failure tests for the recovery guard. These nine tests were executed from the actual source in standalone Rust harnesses, without linking Tauri. The repository's Windows/Linux/macOS CI compiles and executes them again in the full application.
• CI on commit 5b22b3497e879acbab8ce6017df931394e2d64fe: Windows, macOS, and Linux all passed full-workspace Rust checking (--all-targets) and Clippy (-D warnings). Windows frontend/function tests also passed. Full Rust test jobs were still running at this update; see the live CI run for the final outcome.
• Local full Tauri compilation was unavailable because this container cannot install the required GTK/WebKit system packages; the platform compile/lint results above come from CI.
• Still needs an affected-machine check: launch, close/reopen from tray, launch a second instance, and try a display disconnect/reconnect. If it still fails, the new log should identify the last completed stage. CI alone cannot establish that this user's desktop issue is resolved.

No version bump, release publication, authentication changes, or user-data deletion.