fix(app): un-settled threads return to the top of the list - #8231

💭 The files in scope are sorting logic rather than UI styling, so this check about UI consistency—shared primitives, CSS ownership, themes, scroll lists, visual layout—likely doesn't apply here, but I want to sanity-check whether the sorting change falls under any of these rules anyway. I should confirm that web's sortThreadsForSidebar uses the same shared helper as mobile, keeping the logic consistent between platforms. Let me verify the threadSort.ts export and Sidebar.logic.ts just to be safe.

1. browse_code — apps/web/src/lib/threadSort.ts

2. browse_code — apps/web/src/components/Sidebar.logic.ts

💭 No UI/CSS changes here, since the web files are just sorting logic mirroring the mobile helper. Let me double check though—if the web thread type doesn't actually carry unsettledAt through to the sort function, the sort would silently be a no-op, which is worth verifying even though it's not strictly a UI consistency issue.

3. git_tools — unsettledAt

4. git_tools — sortThreadsForSidebar

💭 I'm noticing a discrepancy between the git_grep result and the direct view at the same revision — the grep shows a different function signature and line number for sortThreadsForSidebar than what I saw when viewing the file directly, so I suspect git_grep may be defaulting to a different revision than the one I intended. I want to verify by checking how Sidebar.tsx actually calls sortThreadsForSidebar in the head commit to confirm which signature is real.

5. git_tools — sortThreadsForSidebar

💭 I'm tracing where the sidebar's thread objects get their unsettledAt field from, since the grep only turned up references in Sidebar.logic.ts and its tests—suggesting it's not explicitly passed but inherited from the shared thread type definition. Now I want to check whether the sidebar's active thread list comes from a mapped or projected type that might strip out unsettledAt during transformation. If that field gets dropped in the mapping step, the sort logic would silently become a no-op, which would be a real bug worth flagging.

6. browse_code — In apps/web/src/components/Sidebar.tsx, the active array passed to sortThreadsForSidebar(active) — what is the element type and where do those thread objects come from (which store/selector and TypeScript type)? Does that type include the unsettledAt field from the OrchestrationThread contract, or is it a mapped/narrowed type that drops it? Show the type definition and the mapping code.

💭 Everything looks consistent with no UI styling changes needed. I'm wondering if the shell atoms' reducer fails to update unsettledAt on unsettle events, which would mean the sidebar only reorders after a refetch rather than live—though that's more a behavioral gap than a UI consistency issue. The check's rules focus on component system/CSS/environment routing within apps/web/src, so a shell-state fix would live in packages/client-runtime, outside the include patterns for actions. Still, let me quickly verify whether the shell reducer handles thread.unsettled properly, since it could affect visual reordering behavior in the web app even if the actual fix is out of scope.

7. browse_code — In packages/client-runtime/src/state/threadShell.ts (and any shell reducer), how are thread shell entries updated when a thread.unsettled / thread.settled orchestration event arrives? Does the shell update path set/clear the new unsettledAt field, or does it only touch settledAt/settledOverride? Show the relevant code at commit 9112d00.

💭 The shell path checks out since the server does emit that field via ProjectionSnapshotQuery. With no UI consistency issues found, I need to reconcile the instruction to output exactly "All clear" with the required JSON schema — I'll go with a structured response marking success and using "All clear" as the title and summary.