[Linux] 客户端频繁进入"工作中"假死：proto.staleLogEpoch 协议活锁 + coding_plan_system_busy 叠加，UI 无法打断、退出重进才恢复

环境

• ZCode v3.7.4（磁盘解包方式启动，非直接运行 AppImage）
• Arch Linux，kernel 7.1.6-zen1-1-zen，16GB RAM，Wayland/KDE
• GLM-5.2 coding-plan 订阅

现象

对话进行中客户端突然卡死——UI 持续显示"工作中"，无法打断会话（Esc / 停止按钮无响应），输入的下一条消息发不出去。退出 ZCode 重进后，卡住期间生成的内容立即出现（说明模型输出已落盘，是前端主进程被阻塞，不是请求未完成）。最近几周频率明显上升，已严重影响使用。

日志证据（~/.zcode/v2/logs/2026-08-11.log）

1. 前后端协议活锁

conversationFileChangesV4 在 12 秒内连发 10+ 次，随后被后端以 stale epoch 拒绝：

[19:04:41.720–.901] [rpc:call] zcode-agent.conversationFileChangesV4 OK (耗时从 1.8ms 递增到 172.3ms，连发10次)
[19:04:54.424] [rpc:call] zcode-agent.conversationFileChangesV4 FAIL (5.0ms)
  ZCodeProtocolClientError: proto.staleLogEpoch
    at ZCodeProtocolClient.handleMessage
    at ZCodeStdioTransport.handleStdoutFrame
    at Socket.handleStdoutData
[19:04:54.432] 同上 FAIL (13.7ms) proto.staleLogEpoch
[19:04:54.439] resyncConversationV4 OK  ← 触发重同步，但前端未正确恢复

前端 log epoch 与 zcode-host-local 后端漂移后，每次调用都被 staleLogEpoch 拒，前端疑似未检测到此状态、持续重试 → 活锁。

2. 服务端不稳，加剧触发

[18:58:49.912] [rpc:call] coding-plan-subscription.getEnterprisePricing FAIL "coding_plan_system_busy"
[19:02:41.520] 同上 FAIL (2243.6ms) "coding_plan_system_busy"  ← 挂 2.2 秒

coding_plan_system_busy 近期频繁出现，阻塞前端事件循环，与协议失步高度相关。

3. 退出流程印证"假死非崩溃"

[19:02:17.567] [app-quit] waiting for host process cleanup, forceKillDelayMs=7500, waitTimeoutMs=9000

crashpad 的 completed/new/pending 目录全空，无任何 native crash dump —— 进程未崩溃，是"活着但死锁"。

已排除（非本地资源问题）

• 内存：已用 5G / 16G，swap 零活动，无 OOM，earlyoom 未触发
• CPU/load 正常，iowait=0
• 非 SIGBUS（已用磁盘解包方案，crashpad 无 dump）

期望

1. 前端增加 staleLogEpoch 活锁检测：连续 N 次拒绝后自动强制 resync 或提示用户，而非无限重试。
2. "停止 / 打断"按钮应在活锁场景也能工作（当前完全无响应）。
3. 排查 coding_plan_system_busy 近期频率上升的原因。
4. 若上述属 zcode-host-local 职责，考虑 host 进程心跳 + 自动重启机制。

Start with ~/.zcode/v2/logs/2026-08-11.log and the reported conversationFileChangesV4, staleLogEpoch, resyncConversationV4, and coding_plan_system_busy events. Trace how repeated stale-epoch failures affect resync and the Stop/Esc controls, then verify that the client recovers or gives the user a usable interruption path without requiring a restart.