[BUG] Desktop 1.18.30 (Windows 11): sidecar unresponsive / local server red after every chat, renderer ResizeObserver error storm

Description

Using OpenCode Desktop 1.18.30 on Windows 11: after sending a message — including in a brand-new session — the local server indicator turns red. The sidecar process stays alive and keeps listening on its port, but stops responding:

• The model list doesn't load; switching workspaces is unresponsive
• Messages sent while it is stuck are lost (never persisted; restarting makes them disappear)
• Only restarting the desktop app recovers it — and it happens again on the very next chat

This matches the symptom described in #28332 (closed) and #46121.

Environment

• OS: Windows 11 (Chinese locale)
• OpenCode Desktop: 1.18.30 (packaged; auto-updater reports latest, downgrade allowed)
• Model: opencode-go/deepseek-v4.1-flash (variant max)
• 5 workspaces open in the desktop app simultaneously
• Data dir shared with CLI (~/.local/share/opencode), agents/skills in global config

Steps to reproduce

1. Launch OpenCode Desktop (1.18.30), open a workspace
2. Start any session (new or existing) and send a message
3. Wait for the streamed response
4. The local server becomes red shortly after; the UI stops updating; the app must be restarted

Evidence

main.log (desktop app logs):

[16:44:50.183] sidecar connection started { version: 'v1' }
[16:44:50.192] spawning sidecar { url: 'http://127.0.0.1:53309' }
[16:44:51.522] awaiting server ready
[16:44:51.522] server ready { url: 'http://127.0.0.1:53309' }

renderer.log — error storm during the streamed response (dozens of lines per second):

[2026-09-12 16:45:48.492] [error] ResizeObserver loop completed with undelivered notifications.
[2026-09-12 16:45:48.594] [error] ResizeObserver loop completed with undelivered notifications.
[2026-09-12 16:45:48.609] [error] ResizeObserver loop completed with undelivered notifications.
...
[2026-09-12 16:46:01.522] [error] ResizeObserver loop completed with undelivered notifications.

opencode.log (server side): no crash, no useful error; the process stays alive; no Windows crash events.

Additional context

• Before this became reproducible every time, we cleared a bloated 8.8 GB event table (down to 494 MB) and disabled snapshots (snapshot: false) while debugging — the red-server issue persists, so it does not appear to be data-volume related.
• Related: #28332, #21199, #46121, #30597