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

💭 I'm checking whether migration 043, which adds the unsettled_at column and sort helper, follows the same Effect service import conventions used in other migration files.

1. browse_code — apps/server/src/persistence/Migrations/042_ProjectionThreadLinkedPullRequest.ts

2. browse_code — packages/client-runtime/src/state/threadSort.ts

💭 This PR seems more about a feature change than an Effect service refactor, so I'm scanning the diffs for Effect convention issues—consolidated imports, Layer.succeed usage, ManagedRuntime, error classes—while noting the migration file looks fine. I'm checking ProjectionPipeline.ts, ProjectionSnapshotQuery.ts, and projector.ts, which just add fields, plus looking at the test imports in decider.settled.test.ts. I don't see anything clearly violating Effect service conventions, and the schema changes look fine too. I'm also verifying the pre-existing Services/Layers split for ProjectionThreads isn't something this PR needs to fix, since that's unrelated cleanup, and doing a final pass on imports from "effect" across the touched files.

3. git_tools — from "effect"

4. browse_code — apps/server/src/orchestration/decider.settled.test.ts

💭 That grep result is pre-existing so it's fine to leave alone. I'm checking whether the PR stays consistent, particularly how unsettledAt is handled across the schema, persistence layer, and projection pipeline, since the contracts schema treats it as optional while ProjectionThread requires a nullable date type. Since TypeScript would catch any mismatched row construction, this looks like a correctness detail rather than an Effect-convention issue, and the PR doesn't touch service creation or refactoring — so this check likely comes back clear. Now I need to reconcile the instruction to default to failure with returning "All clear," which suggests the check run's default conclusion state is failure only when actual findings exist. I'm going through the touched files one more time to verify barrel exports and named imports follow the pure-helper exception rather than the service-module rule — threadSort.ts, Sidebar.logic.ts, and threadListV2.ts all import plain helper functions rather than service modules, so those imports are fine. So the verdict stands as All clear. I want to do one last check for any consolidated from "effect" imports across the touched web and package files before finalizing.

5. git_tools — ^import

6. git_tools — ^import|Layer.|ManagedRuntime|runPromise

💭 Everything looks clean with no violations found, so I'll set both the title and summary to "All clear" to reflect the successful result with no findings.