compaction: service restart persists raw InterruptError

[kitlangton]

Summary

Starting a newer OpenCode client replaced the managed service while a manual compaction was in flight. After reconnecting, the original TUI persisted and rendered the expected service-shutdown interruption as a fatal compaction.failed message containing a raw Effect InterruptError stack trace.

Environment

• opencode version: affected TUI 0.0.0-next-15618; old elected service 0.0.0-next-15629; replacement service 0.0.0-next-15649
• OS: macOS 25.5.0, Darwin 25.5.0, arm64
• Terminal: WarpTerminal v0.2026.07.01.09.21.stable_01; TERM=xterm-256color; COLORTERM=truecolor
• Shell: /bin/zsh
• Install/channel: global Bun installation, next channel, managed service
• Active plugins: share-with-team.ts, debug-workspace-plugin.ts, @warp-dot-dev/opencode-warp

Reproduction

1. Keep an existing TUI open and start a manual compaction with /compact.
2. While compaction is running, start a new OpenCode TUI whose installed version is newer than the elected managed service.
3. Allow the version mismatch to replace the managed service and the original TUI to reconnect.
4. Observe the compaction result in the original TUI.

Expected Behavior

An intentional managed-service replacement should either let an in-flight compaction drain, resume it after reconnect, or represent it as a retryable cancellation. The TUI should not present the expected fiber interruption as a fatal compaction failure with an internal stack trace.

Actual Behavior

The original TUI reconnects, but compaction is displayed as a red failure. The durable compaction message has error.type = "compaction.failed" and this raw error:

InterruptError: All fibers interrupted without error
    at SessionCompaction.execute (../core/src/session/compaction.ts:353:19)
    at SessionCompaction.execute (definition) (../core/src/session/compaction.ts:233:26)
    at SessionCompaction.compactManual (../core/src/session/runner/llm.ts:536:40)
    at SessionCompaction.compactManual (definition) (../core/src/session/compaction.ts:333:32)
    at SessionRunner.runPendingCompaction (../core/src/session/runner/llm.ts:564:14)
    at SessionRunner.runPendingCompaction (definition) (../core/src/session/runner/llm.ts:526:41)
    at SessionRunner.drain (../../node_modules/.bun/effect@4.0.0-beta.83/node_modules/effect/dist/internal/effect.js:444:98)
    at SessionRunner.drain (definition) (../core/src/session/runner/llm.ts:560:26)
    at ServerProcess.start (src/server-process.ts:64:29)
    at ServerProcess.start (definition) (../server/src/process.ts:33:29) {
  [cause]: InterruptCause: The fiber was interrupted by:
      at fiber (#490397)
}

Additional Context

• Session: ses_0989d54eaffeaqWQ8NUgwG0zXE
• Model: openai/gpt-5.6-sol-fast, high variant
• Compaction message: msg_f6b4144790010Zy4c4sSjZ2Z23, created at 2026-07-16T14:07:47Z
• At 2026-07-16T14:08:13Z, clients logged event stream disconnected ... error=Transport and the old service stopped its location watchers.
• At 2026-07-16T14:08:15Z, next-15649 started serve --service; it became the elected server and clients reconnected.
• The affected TUI showed the error at 2026-07-16T14:09:49Z.
• The session remained usable afterward; no data loss was observed. The problem is the persisted failure classification and raw internal error presentation.
• Reproduced once during a real version-triggered service restart.
• Related but not duplicate: bug: InterruptError — All fibers interrupted when InstanceStore.dispose races with Agent.list #32755 reports the same Effect interruption symptom from InstanceStore.dispose racing with Agent.list, not compaction during managed-service replacement.

[rasitakyol]

I can take this on the v2 branch. The scoped fix keeps a purely interrupted manual compaction pending for restart retry, preserves any provider error observed before interruption, reconciles stale tools before rebuilding compaction context, and updates the same running compaction projection on retry. The focused interruption regressions and related Core suite are green. Please confirm that v2 is the intended PR base for this next-channel issue; the affected implementation is not present on dev.