fix(desktop): route fetch + WebSocket through native Tauri plugins (mixed-content)

Fixing VITE_API_BASE got login to build a correct absolute URL, but it still
failed with WebKit's generic "Load failed" — WebKitGTK treats tauri://localhost
as a secure origin, so http://127.0.0.1:3000 (and ws://) from inside it is
blocked as mixed content, a WebKit limitation CSP's connect-src can't override.

Added tauri-plugin-http (genuine fetch() drop-in, wired via a new
platformFetch() in origin.ts, used by api.ts + logger.ts) and
tauri-plugin-websocket (not a drop-in — adapted behind a native-WebSocket-
shaped interface in the new platform-ws.ts so use-live-feed.ts needed no
changes). Both route through Tauri's Rust side instead of the webview's own
fetch/WebSocket. Capabilities scoped to 127.0.0.1:3000/localhost:3000, matching
the existing CSP allowlist.

apps/desktop/src-tauri/Cargo.toml

@@ -22,6 +22,17 @@ serde_json = "1"
 # Auto-update: prompt the operator, download a signed update, relaunch.
 tauri-plugin-updater = "2"
 tauri-plugin-process = "2"
+# HTTP client for the SPA's API/WS calls to the local Fastify server. The window
+# runs at tauri://localhost, which WebKitGTK treats as a secure origin — a plain
+# http://127.0.0.1:3000 fetch() from inside it is blocked as mixed content (a
+# long-standing WebKit limitation, not fixable via CSP). Routing through this
+# plugin sends the request via Tauri's Rust side instead of the webview's own
+# fetch, sidestepping the browser mixed-content check entirely.
+tauri-plugin-http = "2"
+# Same mixed-content problem as above, but for the live-feed WebSocket
+# (ws://127.0.0.1:3000 from the secure tauri://localhost origin) — HTTP and WS
+# are separate browser checks, so this needs its own plugin.
+tauri-plugin-websocket = "2"
 
 [features]
 # Used by `tauri dev`/CLI for hot-reload of the Rust side.