fix(background-agent): defer parent-wake when a user message just arrived (fixes #4120) - #4122

Fixes #4120 (related: #3997, #4061).

Problem

When a background subagent emits [ALL BACKGROUND TASKS COMPLETE], the plugin queues a parent-wake that ultimately calls dispatchInternalPrompt against the parent session. If the user submits a new prompt inside the ~250 ms post-dispatch hold window, both writes land on the same OpenCode session-storage file at the same instant. OpenCode's @parcel/watcher (which the plugin doesn't depend on directly but does indirectly trigger via session writes) batches those events into a TSFN callback and dispatches them into a JS env that the renderer has just torn down because the session view re-mounted around the user's new message → napi_fatal_error / SIGABRT on macOS arm64.

Removing the plugin removes the parent-wake, which is why removing OmO eliminates the crash (clean A/B in #4120).

Mitigation

• Before flushPendingParentWake calls dispatchInternalPrompt, inspect the parent session's message tail. If the most recent message is a user message added inside PARENT_WAKE_USER_MESSAGE_IN_PROGRESS_WINDOW_MS (default 2_000 ms), reschedule instead of dispatching. The user's own prompt will drive the model; queued notifications will be re-flushed on the next idle.
• Best-effort unref() of the long-lived pending-retry and dispatched-wake bookkeeping setTimeouts. They previously pinned the host event loop and prolonged the teardown window during which the watcher race can fire.

The new option userMessageInProgressWindowMs is wired through BackgroundManager via a module-level constant and is independently testable.

Tests

parent-wake-user-message-race.test.ts covers:

• fresh user message → dispatch deferred
• latest message is assistant → dispatch proceeds
• user message older than window → dispatch proceeds
• window=0 disables the guard

Honest disclaimer on confidence

During live testing on macOS arm64 with 6 parallel background tasks, the sidecar stayed stable across multiple completion cycles — but the new Deferred parent wake because user message just arrived log line did not fire (grep -c = 0). The existing first-layer defer (isSessionActive(parent) check) and settleAfterSessionIdle(150ms) appear to absorb most realistic timing windows on this hardware. I cannot prove this specific guard fired on the original crash path.

Submitting this anyway because:

1. The original crash pattern (post-completion + immediate user input → napi_fatal_error) is no longer reproducible with this build loaded.
2. The defer-on-fresh-user-message is a defensible safety net regardless of which layer catches it first.
3. The setTimeout.unref() change is unambiguously correct — those timers were preventing clean teardown.

A deeper fix (singleton guard against plugin double-instantiation under @opencode-ai/plugin@local reload, dispose lifecycle for OpenCode plugin reload) is out of scope here and called out in the commit message.

Happy to gather more evidence with snapshot: true and tighter timing if requested before merge.

Summary by cubic

Defers parent-wake dispatch when a fresh user message just arrived to prevent the macOS Electron sidecar crash caused by a prompt race. Fixes #4120.

• Bug Fixes
  • Before dispatching a parent-wake, check the parent's latest message; if it's a recent user message (default 2000 ms), defer instead of dispatching.
  • Adds userMessageInProgressWindowMs (wired through BackgroundManager) to tune or disable this guard.
  • Unrefs retry and bookkeeping timers so they don’t pin the event loop during teardown.
  • Adds tests covering defer/proceed behavior and window=0.

^{Written for commit 3294128. Summary will update on new commits. Review in cubic}