fix(desktop): first-run setup no longer requires input

[huyplb]

Summary

A user hit a bare "Setup failed." on the desktop app's first-run wizard with no further detail, then — once diagnosable — a genuine setup failure that turned out to be two separate real bugs, both found by actually running the fixed app end-to-end.

1. The error-swallowing bug. Tauri commands return Result<T, String> on the Rust side, so a failed command rejects invoke() with a plain string, not a JS Error. Every call site's catch (err) { err instanceof Error ? err.message : fallback } — SetupScreen, both error paths in DatabaseSettings — always took the generic fallback and hid whatever Rust actually returned. Fixed once at the IPC boundary in invokeTauri() (apiBase.ts).

2. First-run wizard needs no input. Previously required a real email (bound to the encryption key) and let you edit the database path before finishing. Now it completes automatically: email defaults to local@foxschema.app (same placeholder the web edition's single-user mode already uses), database stays on its default SQLite location, no form — just a brief "Securing this install…" moment, or a real error + Retry button if something fails.

3. New "Change email" in Settings → Security, since it's no longer set at setup time. New update_email Tauri command re-stores the same key material under the new email's keychain account — no re-encryption, no sidecar respawn.

4. Two real bugs found by actually running the above, both hidden by bug #1 until now:

• SetupScreen's auto-attempt effect only guarded against a stray setState after unmount — it didn't stop completeSetup() from firing twice under React 18 StrictMode's dev-mode double-invoke, racing two sidecar subprocesses against the same SQLite file ("database is locked"). Fixed with a ref that survives the mount/unmount/remount cycle (the standard StrictMode-safe pattern for effects with real side effects).
• enforce_install_binding's JSON parse used stdout.lines().last(), but the captured stdout can carry more than one trailing newline under tauri_plugin_shell's capture (not reproducible via a direct shell invocation of the identical command) — making .lines().last() return an empty line instead of the JSON, always failing regardless of whether the check actually succeeded. Fixed by trimming the whole capture before splitting.
• Also added error logging for both of enforce_install_binding's failure paths — this check's output went nowhere on failure before, which is exactly why bug was invisible.

Test plan

• cargo check (Rust) and cd apps/web && npx tsc --noEmit — both clean.
• npx vitest run — 221 passed, 2 skipped.
• Verified invokeTauri normalizes a plain-string rejection into a real Error (mocked window.__TAURI__.core.invoke).
• Verified the simplified SetupScreen end-to-end in-browser (error/Retry states) and, separately, ran the actual desktop app (npm run dev) through several clean first-runs — reproduced both bug feat: E2E test suite, SQL generator fixes, security automation, versioning #4 issues live via added diagnostic logging, fixed each, and confirmed a completely clean first run: setup_complete: true, sidecar API listening, no errors.
• Verified the new EmailSettings Change → edit → Save flow end-to-end in-browser (mocked Tauri + /api/app-info).