Fix history compatibility and turn presentation regressions (#8010)

* fix(client): preserve history loading on older hosts

Whole-turn paging is optional, but requiring its capability blocked existing history reads before any request was sent. Negotiate the paging enhancement at the client boundary while preserving item-based requests for older daemons.

* fix(app): preserve row ownership during late turn updates

Late lifecycle events retagged the newest row even when they updated an earlier call, causing the next update to append a duplicate tool ID. Assign turn membership only to rows written by the event before finalizing unrelated reasoning.

Co-authored-by: luke <luopeihuan@gmail.com>

* fix(app): preserve reasoning continuity and turn expansion controls

* fix(app): hide reasoning inside collapsed turns

---------

Co-authored-by: luke <luopeihuan@gmail.com>

docs/protocol-compatibility.md

@@ -2,7 +2,7 @@
 
 The app and the daemon are separate products that ship separately. A user updates the app from an app store or a desktop auto-update; they update the daemon when they feel like it. Every combination happens in the wild: new app against an old daemon, old app against a new daemon, and both sides months apart.
 
-In development both sides are always the same version, which is why this is the constraint contributors miss most often.
+Development can have the same version drift: an app reload picks up new code while a long-running daemon keeps its loaded version. Check the connected daemon version when diagnosing behavior that crosses this boundary.
 
 Two contracts follow from it.
 
@@ -38,7 +38,7 @@ The app checks for the capability and either runs the feature or tells the user
 - **No defensive branches spread through the feature.** Detection happens in one place, and everything downstream reads a clean shape.
 - Capability flags live in `features` on the `server_info` message (`packages/protocol/src/messages.ts`, the `server_info` schema).
 
-Existing functionality keeps working across versions because of the protocol contract. Gating a new feature never substitutes for that.
+Existing functionality keeps working across versions. Never gate an established request on a new enhancement: negotiate the optional enhancement at the client boundary and preserve the existing request for older hosts. Whole-turn pagination can require a capability; reading conversation history cannot.
 
 ## Client capability ownership
 

docs/timeline-sync.md

@@ -50,10 +50,11 @@ all currently available rows of an active run. There is no per-turn cap: a large
 exceed the target. Local history mounting uses the same boundaries so revealing older rows
 does not change the collapse state of a turn already displayed.
 
-`wholeTurns` is optional for existing SDK callers. The app requires
-`features.wholeTurnTimeline` once at the client fetch boundary; unsupported hosts receive an
-update-host error. Forward catch-up stays incremental, but its reset snapshot honors the
-whole-turn request. Source coverage still includes interleaved tool updates.
+`wholeTurns` is a preference negotiated once at the client fetch boundary. Hosts advertising
+`features.wholeTurnTimeline` receive it; other hosts receive the existing item-based request.
+Reading history remains available on older hosts, whose pages can still split turns. Forward
+catch-up stays incremental, but its reset snapshot honors a supported whole-turn request.
+Source coverage still includes interleaved tool updates.
 
 Canonical IDs define runs. With missing IDs, human prompts, heartbeats and typed received
 agent messages each start a fallback turn. This deterministic fallback is shared by paging