Summary

Adds the deno desktop subcommand for building desktop apps from Deno projects.

Core:

• deno desktop <entry> compiles a project into a self-contained desktop app, built on WEF (prebuilt backends downloaded from github.com/denoland/wef/releases, pinned via Cargo.lock, SHA256-verified, cached under <deno_dir>/wef/<version>/). WEF_DEV_DIR points at a local wef checkout for development.
• Backends: cef (default, bundled Chromium), webview (OS webview), raw (winit, no engine).
• Deno.serve() in the entry auto-binds to the port the webview navigates to (via DENO_SERVE_ADDRESS).

Framework auto-detection (cli/tools/framework.rs): Next.js, Astro, Fresh, Remix, Nuxt, SvelteKit, SolidStart, TanStack Start, Vite SSR. Prod server runs by default; dev server runs under --hmr.

HMR (--hmr): framework projects use the framework's dev server; non-framework apps use file-watch + Debugger.setScriptSource hot-swap with the runtime and CEF staying alive.

Deno.BrowserWindow API (cli/tsc/dts/lib.deno.desktop.d.ts): window lifecycle (show/hide/focus/close/reload), size/position, always-on-top, navigation, bind/unbind RPC to webview JS via bindings.<name>(), executeJs, app/context menus, native window handle, keyboard/mouse/wheel/resize/focus events.

Runtime integration: prompt()/alert()/confirm() become native popups; uncaught errors show a native alert and optionally POST to desktop.errorReporting.url.

Auto-updater: Deno.desktopVersion + Deno.autoUpdate({ url, interval, onUpdateReady, onRollback }). Polls <url>/latest.json, applies bsdiff patches (qbsdiff) to the dylib, stages for next launch, rolls back on failed launch.

Unified DevTools (--inspect / --inspect-brk / --inspect-wait): single DevTools session showing both the Deno runtime V8 and the CEF renderer V8 as attached targets — one Console dropdown (Renderer / Deno), one Sources panel with both threads. Implemented as a CDP multiplexer in cli/tools/desktop_devtools.rs. --inspect-brk pauses both isolates (Deno via its own mechanism, CEF via injected Debugger.enable + Debugger.pause before navigation).

Dock / Tray: Deno.dock (macOS) and Deno.Tray (cross-platform) for status-area icons with tooltips, dark-mode icons, and context menus.

Distribution / cross-compile: --target and --all-targets download prebuilt denort + WEF backends for the target triple. Outputs:

• macOS: .app bundle (framework under Contents/Frameworks/), .dmg via hdiutil
• Windows: .exe + DLLs directory
• Linux: app directory, .AppImage via appimagetool

OS-specific limitations

Several features are currently wired up for a subset of platforms. They degrade gracefully (the rest of the app still works) but are worth calling out:

• Auto-updater is unix-only. apply_pending_update, get_dylib_path, and AutoUpdateState are all #[cfg(unix)]. On non-unix (Windows) update_rolled_back is hardcoded to false and auto_update_state is None, so the staged-update / patch-apply / rollback path is a no-op there. Bringing it to Windows means implementing the dylib-swap + pending-update application for that platform (likely behind a small platform module so the #[cfg] branches in run_desktop/laufey::main! collapse).
• NAPI native-addon support is unix-only. promote_dylib_symbols_to_global (re-dlopens the runtime dylib with RTLD_GLOBAL so NAPI symbols are visible to addons like next-swc) is #[cfg(unix)]. On Windows, frameworks that pull native addons may fail to load those addons.
• Notification permissions are macOS-specific. The LAUFEY backend is launched via disclaim_spawn (posix_spawn with TCC responsibility disclaimed) so it becomes its own permission principal; without it UNUserNotificationCenter.requestAuthorization fails. The non-macOS path is a plain tokio spawn with kill_on_drop.
• Linux is X11-only (no native Wayland). The generated launcher forces --ozone-platform=x11 + GDK_BACKEND=x11, because the LAUFEY mouse/focus/resize event monitor uses XI2 on X11. On Wayland sessions it runs through XWayland; native Wayland is unsupported.
• Deno.dock is macOS-only (no-op / unavailable elsewhere).
• Icon sets are not supported in --hmr mode (any platform). IconConfig::Set errors with "icon sets are not supported in --hmr mode yet"; only a single icon path works under --hmr.

Not yet implemented

• Notarization / stapling. Codesigning is implemented (macOS, via macos.codesignIdentity in deno.json, with an ad-hoc signature fallback for unsigned builds), but there's no notarytool submission / stapler step yet.
• Windows MSI, Linux .deb / .rpm installers
• Clipboard, secureStorage
• Test coverage (unit + integration)

Closes #3234