Desktop (Windows): boot stall — renderer 'Failed to fetch', embedded server binds port then stops listening (V8 zone OOM observed); TUI/serve fine on same box/DB/config

Description

On one specific Windows x64 box, the opencode desktop app consistently fails to boot: the renderer never reaches a working server connection. The TUI/CLI and opencode serve on the SAME machine, SAME database, SAME config work perfectly.

What happens at boot (every launch, deterministic)

1. Embedded server boots inside the Electron main process; opencode.log shows the normal instance bootstrap (10 recent projects, ~25-28 s total).
2. A TCP listener appears briefly at ~15-34 s (loopback, e.g. 51040/52523/54931/56697), then disappears permanently.
3. opencode.log ends right after the last bootstrapping <dir> + init lines — no listening line, no ERROR, no further lines for 10+ minutes (soaked).
4. Renderer console: Failed to finish bootstrap instance TypeError: Failed to fetch / Failed to load sessions TypeError: Failed to fetch (oc://renderer/assets/main-*.js, fetchMessages/loadMessages stack) — retries for minutes, then the error toast.
5. Electron stderr once showed: ERROR:electron\shell\common\node_bindings.cc:189] OOM error in V8: Zone Allocation failed - process out of memory (~68 s after launch) in one of the app processes; the app keeps running with 5 processes but never listens again.

What we excluded (all verified on the box)

• Database is healthy: sqlite write-path probe (INSERT/UPDATE session, message, part, event; rollback) PASSES; PRAGMA integrity_check = ok; DB was compacted 7.15 GB → 5.73 GB the same night (event rows skipped, schema kept) — behavior identical before and after.
• Both versions stall identically: 1.18.31 and 1.18.30 (clean NSIS downgrade/upgrade, verified ProductVersion).
• Config content is not the trigger: booted with plugins [] and MCP disabled — same stall; booted with full config — same stall.
• Profile is not it: fresh --user-data-dir — same stall.
• Singleton lock: reproduced with zero prior instances and no stale lock files — same stall.
• Proxy off (WinINET ProxyEnable=0, winhttp direct, no env proxies); models.dev reachable; provider reachable.
• RAM fine (15.8 GB total, 6.5 GB free at boot), no other opencode processes running.
• File-watch load not it: moved the 400k-683k-file repos out of the scanned root, added watcher.ignore — same stall.
• Not project-scope: launching with an explicit project dir argument — same stall.

What DOES work on the same box, same DB, same config

• opencode run "..." (headless) — creates sessions fine, end-to-end OK.
• opencode serve --port N — HTTP /doc answers 200 in ~5 s.
• TUI — works.

So the failure is specifically in the desktop's server↔main-process handoff (the server never reaches/survives its "listening" handshake inside the desktop).

Environment

• Windows x64 (MSI-provisioned dev box), opencode desktop 1.18.31 (also reproduced on 1.18.30), CLI 1.18.31.
• ~300 git repos under C:\Users\user\Documents\GitHub (recent-projects bootstrap list ~10 projects), some projects contain large binaries (ffmpeg exes, MP3s, 100+ MB docx).
• 13 project plugins (all disabled during one test — no change) and 1 local MCP server (also disabled during one test — no change).

Question

What is the expected server↔main readiness handshake in the desktop build, and is there a known Windows-specific failure mode (or a debug flag, e.g. env var) that would log the embedded server's post-bootstrap phase? Happy to run any instrumented build or capture more data.

Trace the desktop embedded-server startup and renderer bootstrap around the reported fetchMessages/loadMessages paths, comparing them with the working opencode serve flow. Use opencode.log and Electron stderr to capture the post-bootstrap readiness phase; done means the Windows desktop either completes its listening handshake and renderer fetches succeed, or the failure is isolated with actionable logging.