cli: service becomes unresponsive under multi-session load — single process bottleneck

Description

When running 5+ concurrent sessions, the opencode service becomes severely degraded. A single Node.js process hitting single-core CPU saturation causes:

• Creating new sessions takes excessively long
• Switching between sessions shows the session list loading for an extended period
• Switching models within a session is also extremely slow
• The entire service becomes unresponsive until CPU usage drops

The root cause appears to be that all active sessions share a single Node.js process. When one session's workload (e.g., a long-running LLM response or tool execution) saturates a CPU core, all other sessions — including UI operations like listing sessions or switching models — are starved and become unresponsive.

Steps to reproduce

1. Open 5 sessions simultaneously in opencode
2. Trigger heavy workloads across multiple sessions (e.g., long-running code generation, tool execution)
3. While workloads are running, try to create a new session
4. Try to switch between sessions — observe the session list taking a very long time to load
5. Try to switch the model in any session

Expected Behavior

• UI operations (session list, model switching, creating new sessions) should remain responsive regardless of background workload
• Heavy computation in one session should not block or degrade other sessions
• Consider using Node.js worker threads to isolate session workloads, so a CPU-bound task in one session does not starve the event loop shared by all sessions

Actual Behavior

• Session list loading takes an abnormally long time under load
• Creating new sessions is extremely slow
• Switching models hangs
• The service becomes effectively unresponsive until the CPU-intensive work completes

Additional Context

• opencode version: 2.0.3
• OS: Windows_NT 10.0.26200 (MINGW64_NT-10.0-26200, win32 x64)
• Terminal: Git Bash (xterm-256color)
• Shell: /usr/bin/bash (MINGW64)
• Install/channel: npm global, latest
• Active plugins: none

Possible improvement: If active sessions could use dedicated worker threads, a CPU-saturated session would only block itself, not the entire service. This would make multi-session usage significantly more resilient.