Release exp: preserve visible reasoning on deferred anchor paint (#6048). Thanks @franksong2702.

CHANGELOG.md

@@ -67,6 +67,8 @@
 
 ### Fixed
 
+- **Live reasoning no longer drops or double-renders when the turn anchor defers a paint.** On the streaming reasoning render, when the assistant-turn anchor accepted a reasoning event but deferred actually painting it, the reasoning text could go missing — and earlier attempts to fix that could briefly show the same reasoning under two owners or, with multiple reasoning segments, update the wrong row. The fallback now matches the exact anchor row identity (`run_id:seq`), so the right segment updates in place, other rows are untouched, and no duplicate owner appears — across Transparent, Compact, and hide-all modes. Thanks @franksong2702. (#6048, #5720)
+
 - **Deleting a session now cleans up its delegated subagent sessions too (no orphaned children).** When you delete a parent session, the delegated/subagent sessions it spawned (and their on-disk transcript artifacts) are now cascaded and removed, including Agent-migrated legacy delegates — while unrelated sessions, sibling branches, and any still-live child are never touched. The cascade fails closed on any uncertainty (can't confirm liveness, missing/unqueryable state.db, or no cross-process lock primitive → it skips destructive cleanup rather than risk over-deleting), cross-process cleanup is serialized with a file lock so two WebUI workers can't race, and a partial cleanup is reported honestly instead of shown as full success. Thanks @pxxD1998. (#5926, #5307)
 
 - **Agent updates no longer report a false failure when the gateway restart is transient — and never mask a real failure.** During an agent update, the launchd/gateway restart subprocess can briefly exit non-zero while the old process is being replaced; that was surfaced as a whole-update failure. The updater now confirms the outcome by the actual gateway PID for the exact profile being updated (retrying the restart once), so a genuine process handoff is reported as success — while a real restart failure, an unknown/ambient PID, a wrong-profile confirmation, or a compatibility-wrapped status helper that can't confirm the specific PID all fail closed (never masked as success). Restart targeting and the PID check are pinned to the update's profile (root aliases normalized), and malformed profile names are rejected before launch. Thanks @franksong2702. (#6054, #6045)