fix(client): float inbox threads on recent activity instead of creation order

[ZongrongLi]

Fixes #16412 (repro and root-cause analysis there).

Problem. The flat Threads inbox never re-sorts on activity: it renders creation-descending order even though every client thread object already carries fresh updatedAt / latestUserMessageAt / latestRun stamps. A thread with a new user message and a completed run today still sat at its creation rank (#10 of 18).

Fix (all in shared packages/client-runtime, so web and mobile follow):

• activeThreadAnchorTimestampMs (state/threadSort.ts): the anchor is now the max over createdAt, unsettledAt, latestUserMessageAt, updatedAt, latestRun.requestedAt/completedAt instead of just creation/unsettle, so keyless rows in sortActiveThreadsByOrderKey float on activity. Saved activeOrderKey arrangement is untouched.
• sortInboxThreadsByReturn (state/threadInbox.ts): same two stamps added to its max, next to the existing run bounds and observedReturnAt.
• Rewrote the docstrings/comments that documented the old static order (threadSort.ts, mobile sortThreadsForListV2 wrapper). Pinned-key planning, settled/snoozed ordering, and the Working-section send-order are untouched.

Tests. Extended threadSort.test.ts (anchor activity cases + keyless float case), Sidebar.logic.test.ts (inbox puts the recently-changed thread first with no new run), threadInbox.test.ts fixture, mobile threadListV2.test.ts (renamed the creation-order test to the new contract + added a float case). Updated one mobile layout test that pinned the old static order. Suites green: client-runtime threadSort/threadInbox/threads-sync (82), web Sidebar.logic (146), mobile threadListV2 + threadOrderAvailability (106); typechecks green for client-runtime, web, mobile.

Live verification. I patched the equivalent code path in a locally running nightly bundle and confirmed the real inbox re-sorts (the stale thread above moved from #10 to #3). Before/after screenshots were captured locally and can be attached here on request.

Disclosure. This changes behavior the old docstring described as static, so I'm treating #16412 as the direction discussion — happy to narrow, split, or rework per review.

Built with Muse Spark via the OpenCode harness.

[ZongrongLi]

Related prior work I found after opening: #15216 (rebuild of #12895, from Ideas discussion #6964) adds an opt-in Configured order / Last message choice with UI controls on web and mobile, keeping the default unchanged. This PR instead changes the default anchor behavior directly (verified live against a running nightly). Flagging the overlap for reviewers: if #15216 is the accepted direction, happy to close this in its favor — #16412 stands as an additional user data point either way.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — The shared client sorting changes the default web and mobile thread-list order from creation order to recent activity, affecting existing user-facing paths even though the diff is focused and tested. Because this changes a product default, the change warrants human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[ZongrongLi]

Closing in favor of #15216 per discussion above — keeping #16412 as the user evidence. Happy to rework if maintainers prefer this approach.