Cron fire mid-reply swallows the previous assistant reply; unrecoverable via Ctrl+O #2620

Summary

When a scheduled cron reminder fires while the assistant's previous reply is still on screen (user hasn't responded yet), that reply disappears from the visible transcript. It cannot be recovered — scrolling back shows the turn was replaced by the cron turn, and Ctrl+O expand does not bring the lost reply back.

Environment

• Kimi Code CLI 0.38.0
• macOS (Apple Silicon), running inside cmux
• A recurring cron created via CronCreate (23/25 * * * *)

Repro

1. Create a recurring cron reminder (CronCreate).
2. Have the assistant produce a long, substantive reply (in our case: five drafted GitHub issue replies + product-policy discussion).
3. Before the user responds, the cron fires.
4. The cron prompt is injected and a new turn starts immediately.
5. The previous assistant reply is gone from the transcript — Ctrl+O shows only tool-call fragments, not the lost reply text.

Expected

• A cron fire should never destroy transcript content. If the user hasn't consumed the previous reply, the fire should be queued/coalesced AFTER the reply is durably committed to the transcript.
• Lost replies should at minimum remain recoverable via scrollback / Ctrl+O.

Impact

Real user-facing data loss: the user had read only part of the swallowed reply ("I only finished reading the five drafts; the #86/#79 sections were gone"). The content existed nowhere else and had to be re-generated.

Notes

• Possibly related family: Edit/Write tools report success but never write to disk (0.38.0, macOS) #2617 (session-state corruption after Compact/resume — different symptoms: Edit/Write fake success + ghost cron delivery). This one needs no corruption: just a long reply + a mid-display cron fire.
• Screenshots of the swallowed state available on request (shows the reply cut off mid-render and the "Scheduled reminder fired" block taking over).