fix(clients): keep opening responses visible after turns settle - #7723

💭 This diff only touches logic in threadActivity.ts and MessagesTimeline.logic.ts, with no styling changes, so the UI consistency check mainly concerns those logic files and their tests. I want to verify the logic change doesn't inadvertently affect rendering behavior, like fold anchoring, so I'm checking the actual usage. I'm comparing how web and mobile identify the first assistant entry per turn — web restricts the group to assistant messages and work entries, skipping user messages, so the first message entry in that group is the answer. Now I'm checking whether mobile's equivalent computation, which scans the full feed rather than a filtered group, handles this the same way. Since this is purely logic rather than styling, I want to verify there's no visual side effect from anchoring the fold row mid-turn instead of at the start — things like spacing or margin assumptions in the timeline renderer that expect the fold row to be first. I'll look at the web renderer's turn-fold handling to confirm nothing breaks when the anchor shifts position, keeping in mind only apps/web files are in scope here. I should check MessagesTimeline.tsx around lines 900-1000 and 1104 for spacing logic that assumes a specific fold row position. Nothing seems broken styling-wise. I'm checking whether showAssistantMeta is computed correctly for the first assistant message now that it stays visible, and whether the fold row separator looks right between it and the terminal message — both seem fine, consistent with existing behavior for already-expanded commentary. I'm also verifying that firstAssistantEntry correctly scopes to assistant messages within a group, and considering edge cases like a turn starting with a work entry before the first message, or an empty terminal set — these seem intentional and consistent between web and mobile. Overall this diff looks like pure logic and test changes rather than anything affecting shared UI components or styling. Checking scroll anchoring and virtualization concerns, I don't see any issue — the fold row keeps a stable id, and mobile being out of scope doesn't create inconsistency since its behavior already matches. I'm concluding there are no findings here, so I'll report this as all clear in the response.