fix(desktop): server spawn resilience

[adamdotdevin]

GPT 5.2 xhigh:

That message is coming from the desktop app’s startup path: it spawns the bundled sidecar (opencode-cli … serve …) and then waits up to 30s for GET /global/health to succeed. If that never goes healthy, packages/desktop/src-tauri/src/lib.rs throws Failed to spawn OpenCode Server….

Why reports often show empty “Logs:” today

• The desktop only buffers sidecar stdout/stderr, but the CLI writes most diagnostics to its own log file unless run with --print-logs.
• We also weren’t recording early process termination, so a sidecar that exits immediately (or never prints) looks like a generic 30s timeout.

I patched the desktop backend to make these reports actionable:

• Start the sidecar with --print-logs --log-level WARN so real errors land in the buffered logs.
• Record CommandEvent::Error and CommandEvent::Terminated (exit code/signal) into the buffered logs.
• Fail fast if the sidecar terminates before becoming healthy (instead of always waiting for the 30s timeout).
• Add a [SPAWN] … line so even “silent” failures show what we tried to run.

Changes are in:

• packages/desktop/src-tauri/src/cli.rs
• packages/desktop/src-tauri/src/server.rs
• packages/desktop/src-tauri/src/lib.rs

If you ship a build with this, the next batch of reports should include exit code/signal + stderr, which usually immediately points to the root cause (missing libs/GLIBC, illegal instruction on older CPUs, shell/env issues, etc.).