Chat pane frozen after app restart: messages persisted to DB but never rendered; input queue promotes out of order (0.16.5, Windows)

Environment

• OS: Windows 11 Pro (10.0.26200), display scaling 150%
• ZCode: Desktop 0.16.5 (win32)
• Model channel: Z.ai (builtin GLM-5.3)
• Session type: long-running interactive task, ~780k tokens of 1M context, thousands of persisted events including runtime/workspace_checkpoint entries

Summary

After an app restart, the transcript pane of one specific task froze at its pre-restart snapshot: new user input is accepted by the composer and persisted, and the agent runtime keeps running turns and writing messages to the database with gapless sequences — but none of it is ever rendered in the pane. The pane keeps showing status "Stopped" and an idle composer. A fresh fork of the same session renders normally.

Steps to reproduce

1. Work in one long-running interactive task for a long period (context several hundred k tokens; many persisted workspace checkpoints — this session's resume logs cold_merge.unclassified_event_preserved with 376 checkpoint_created events vs 40 for the next-worst session).
2. Restart the ZCode desktop app while a turn is in flight (in our case: shutdown at 12:02:33Z with a model request started at 12:01:54Z that never completed or failed — no turn.failed/turn.completed ever logged for it).
3. Restart the app again later (second startup at 13:27:26Z; session resumed, hydration warning above repeats).
4. Reopen the affected task from the sidebar and send a message.

Expected behavior

The transcript pane shows the new user message, the resumed turn's streaming output, and a non-Stopped status. Input queue items promote in order once the running turn completes.

Actual behavior

• The pane never updates: it stays at the pre-restart snapshot (last visible message from before the restarts), status "Stopped", composer placeholder "Ask for follow-up changes".
• Pressing Enter clears the composer; the message is admitted into session_input (kind sendText, delivery queue) — so the input path works — but nothing renders.
• Meanwhile the runtime is alive: it promoted the first send (delivery startNow), started a turn at 13:27:31Z, and kept minting message rows every ~15–30 s with gapless sequence values for 15+ minutes (user + assistant messages), all invisible in the pane.
• Queue promotion is out of order: a later queue item (admitted_sequence 78) was promoted while three older items (75–77) remain admitted indefinitely.
• Stuck queue items from a previous restart cycle were silently discarded with status_reason: "session_resumed" at the next app startup.

Evidence

Sanitized event timeline (payloads stripped; timestamps, event names, ids only) attached: zcode-09-07-fullstack-timeline.txt. Times are UTC (host local = UTC+1). Key lines:

• 12:02:33Z — app shutdown; the in-flight model request (started 12:01:54Z) never completes; its turn is never closed.
• 13:27:26Z — bootstrap.app.startup.started → session.resumed → warn zcode_protocol.v4.hydrate_three_source_merge / cold_merge.unclassified_event_preserved, count 376, all checkpoint_created.
• 13:27:31Z onward — turn.started, model.request.started/completed, session.event.persistence.completed cycling continuously (turns keep running) while the pane shows no change.
• ~/.zcode/cli/db/db.sqlite (queried read-only on copies): message sequences gapless 1147→1176+; session_input statuses as described above.

Workaround: forking the affected task produces a fresh session whose pane renders normally. Rebuilding the pane (switching tasks / restarting) should rehydrate the missing history from the DB.

Suspected area

The renderer's per-session live-event subscription appears not to be (re)established for a session resumed with a dangling turn / heavy unclassified cold events: cold hydration at view-build works (history up to the freeze point renders), but no post-restart events are ever delivered, while persistence, the agent runtime, and the composer→main-process input path all keep working. The out-of-order queue promotion and discard-on-resume behavior look like secondary symptoms of the same resume path.

Start with the attached zcode-09-07-fullstack-timeline.txt and read-only copies of ~/.zcode/cli/db/db.sqlite, tracing the resumed session from cold hydration through live event delivery. Investigate the renderer's per-session subscription around the dangling turn and unclassified cold events, then verify that reopening the task renders post-restart messages, reports the running status, and promotes queued inputs in order.