fix(desktop): prevent background service SIGKILL loops and tune SQLite WAL concurrency - #53387

Issue for this PR

Closes #51216

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

On Windows (and systems with high I/O or database load), the desktop app frequently kills its own background service (\opencode-cli) while the service is busy handling transactions or checkpoints, causing a continuous ~60s restart loop, aborted turns (\HTTP 499), and process contention.

Root Causes Identified:

1. Aggressive Supervisor Timeouts: \defaultEnsureTiming\ configured
   equestTimeout: 2_000\ (2s) and evicted the registered service after 3 consecutive timeouts. A database transaction, WAL checkpoint, or git snapshot blocking the HTTP event loop for just 6.1s caused the supervisor to declare the service unresponsive, SIGTERM/SIGKILL the active PID, delete \service.json, and trigger a restart storm.
2. Contender Race Condition: When
   egistration.service === undefined\ (e.g. while the server is starting or momentarily saturated), \pool.shouldRecruit(true)\ spawned a contender child process after \spawnDelay: 5_000. Even though the incumbent PID was running in the OS process table, contenders were launched concurrently, racing for database locks and overwriting \service.json.
3. SQLite Default Synchronous Mode: In WAL mode, SQLite defaults to \PRAGMA synchronous = FULL\ on each new connection unless explicitly configured. With large databases or multi-session loads, \FULL\ forces synchronous disk flushes per transaction commit, inducing severe I/O stalls and lock contention.
4. Premature SSE Stream Drops & Sidecar Reconnect Churn: In Solid \createClientConnection, \oregroundIdleThreshold\ was set to 20s and \defaultIdleTimeout\ to 45s. Switching windows or backgrounding the desktop app frequently tripped this threshold, tearing down the stream. The desktop renderer's \createSidecarResolver\ then called
   econnectService()\ IPC unconditionally, re-entering \Service.ensure()\ and accelerating supervisor churn even though the backend process was healthy.

Changes Made:

• \packages/core\ (\database.ts, \sqlite.bun.ts\ & \sqlite.node.ts):
  • Configured \PRAGMA synchronous = NORMAL;\ and raised \PRAGMA busy_timeout = 30000;\ (30s) on non-readonly database connections. As documented in SQLite's WAL design, \NORMAL\ is fully crash-resistant in WAL mode and avoids \sync\ lock stalls.
• \packages/desktop\ (\main/storage/database.ts,
  enderer/startup/initialization.ts):
  • Added \PRAGMA busy_timeout = 30000;\ to desktop SQLite storage initialization to prevent transient lock failures.
  • In \createSidecarResolver, probe /api/info\ on the current sidecar URL before invoking
    econnectService()\ IPC. If the incumbent server is responsive, reuse it immediately without triggering supervisor re-checks.
• \packages/client\ (\service-timing.ts, \promise/service.ts, \�ffect/service.ts, \solid/connection.ts):
  • Increased
    equestTimeout\ (2s -> 10s), \spawnDelay\ (5s -> 15s), \maxSpawnDelay\ (30s -> 60s), and \promiseTimeout\ (120s -> 180s) in \defaultEnsureTiming.
  • Raised supervisor eviction threshold from 3 to 10 consecutive timeouts (\ imeouts.count >= 10), allowing busy background processes adequate headroom before eviction.
  • Guarded contender recruitment in both Promise and Effect service loops: contenders are never spawned when the incumbent PID is confirmed alive in the OS process table (!stopped(pid)\ / \isPidAlive(pid)).
  • Relaxed SSE \defaultIdleTimeout\ to 120s and \oregroundIdleThreshold\ to 300s (5m) to avoid spurious reconnections on window switches.
• \packages/app\ (
  untime/server/request-queue.ts):
  • Raised
    equestStallMs\ (2s -> 10s) to prevent false-positive thrashing warnings during initial session loading.

How did you verify your code works?

• Validated with unit tests in \packages/client\ and \packages/core:
  • \�un test test/service-contender-pool.test.ts\ passes (6 pass, 0 fail).
  • \�un run --filter @opencode/client typecheck\ and \�un run --filter @opencode/core typecheck\ exit code 0.
• Verified live on Windows 11 with a high-volume SQLite database (500k+ messages):
  • Service probe latency dropped from >2.5s / timeout down to ~50ms.
  • Zero background service kills, zero contender collisions, and zero spurious restart loops over sustained multi-hour sessions.

Screenshots / recordings

Not a UI change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR