[Bug] Remote session sidebar spinner spins forever after automatic background compact — no turn starts after compact.completed (3.9.2 / 0.16.5)

提交前确认 · Pre-submission checklist

• I searched existing issues and confirmed this isn't a duplicate. (Searched "spinner", "compact", "stuck loading remote" — closest are #357 and #114, both different.)
• I've read CONTRIBUTING.md.

问题类别 · Category

对话 / Agent 交互 · Agent chat

涉及的 Agent 框架 · Agent framework

ZCode Agent（自研）

严重程度 · Severity

影响体验 · Major (works but degraded)

复现频率 · Reproducibility

仅一次 · Once (but the full server log trace is available; likely deterministic after every background compact on a remote session)

问题描述 · Description

On a remote-SSH session, after an automatic background compaction finishes, no new turn starts. The session entry in the desktop sidebar keeps showing the spinner indefinitely, with no visible activity and no error. The session only recovers when the user manually sends a new message.

复现步骤 · Steps to reproduce

1. Open the ZCode desktop app on Windows, connected to a project on a remote Linux server over SSH.
2. Work in one long session until the context limit triggers an automatic background compact.
3. Wait for the compact to finish.
4. The sidebar session entry keeps spinning. No assistant response arrives and no job is shown as running. It spun for 6+ minutes until I typed a new message.

期望表现 · Expected behavior

After compact.completed, either the interrupted turn resumes automatically, or the session returns to idle state with the spinner cleared (and an error event if the resume fails).

实际表现 · Actual behavior

The client-side session spinner spins forever. Server log shows complete silence between compact.completed and the user's next message — no turn.started, no model request, no error event. The client is never told the session is idle again. Sending any new message unsticks it: a normal turn starts, consumes the compacted summary, and the session works normally afterwards.

ZCode 版本 · ZCode version

Desktop app 3.9.2 (Windows control surface); server-side session record version: 0.16.5

设备 / 系统 / 浏览器 · Device / OS / Browser

• Desktop: Windows, ZCode app 3.9.2
• Server: Debian GNU/Linux, kernel 6.1.0-37-amd64 x64, Node v22.16.0, zcode-server 3.9.2 launched via Tailscale SSH
• Workspace: remote:ssh:x-os:22:cj:/home/cj
• Model: builtin:zai-coding-plan / GLM-5.3-Flash

截图 / 录屏 / 日志 · Screenshots / Recordings / Logs

Server-side trace for the affected session (sess_30fa664f-5247-40b9-9c20-0e23c8f080b1, trace_id 7b5e612e-41aa-443a-b0e4-06d103745604), from ~/.zcode/cli/log/zcode-2026-08-28.jsonl (timestamps UTC):

2026-08-28T00:42:26.492Z  turn.completed                 (turn_e65372af… — previous normal turn ends)
2026-08-28T00:43:26.250Z  "v4 background compact started"
2026-08-28T00:43:26.255Z  compact.started                (turn_de0a5797…)
2026-08-28T00:45:03.021Z  model.sdk.stream.completed     (compact model call succeeds)
2026-08-28T00:45:06.135Z  compact.completed

—— nothing for 6 minutes: no turn.started, no model request, no error ——

2026-08-28T00:51:07.049Z  "v4 sendText accepted"         (user's next message)
2026-08-28T00:51:07.056Z  turn.started                   (turn_5a50343e… — session works normally again)

Additional observations from the session database:

• At compact.completed, two duplicate synthetic user messages were persisted (source: resume_referenced_session_context, both at the same millisecond). Possibly related.
• No assistant message exists between the resume-injection messages and the next real user message.
• Session time_updated stayed frozen at the compact timestamp until the new user message arrived — so the server itself considered nothing in flight, while the client kept showing "busy".

Suggested fixes to consider:

1. After a background compact, resume the queued/pending turn (or emit turn.completed / turn.error so the client clears the spinner).
2. Investigate the duplicated resume_referenced_session_context injection.
3. Have the client spinner derive from an authoritative server busy-state with a timeout, instead of a fire-and-forget event.

Start by tracing the server-side handling of compact.completed through turn lifecycle and the desktop sidebar's busy-state updates. Use the provided JSONL trace and session database observations, especially the duplicate resume_referenced_session_context messages, as the reproduction evidence. Done means the interrupted turn resumes or the session emits a terminal event that clears the spinner, with an error reported if resumption fails.