fix: keep auto-settle policy consistent across clients

[PixPMusic]

What Changed

• moved the inactivity auto-settle threshold from device-local client settings into server settings owned by each environment
• made web, desktop, and mobile classify each thread with its owning environment's streamed policy
• kept inactivity classification derived: clients do not send thread.settle, and the server does not schedule settlement events
• added version-skew gating, multi-environment regression coverage, and user documentation

Why

Web/desktop read sidebarAutoSettleAfterDays from local client persistence, while mobile hard-coded the default of three days. A desktop configured for seven days and a mobile client connected to the same server could therefore put the same thread in different shelves.

The existing server-settings RPC is already remotely writable and streamed to connected clients, so the policy now lives there. Explicit settle/un-settle remains the durable server lifecycle; crossing the inactivity threshold only changes the derived list classification. This avoids clients racing automatic settle commands and lets a policy change reclassify threads immediately.

The default remains three days. The legacy client field and exported names remain decodable for downgrade/source compatibility, but local values no longer drive upgraded clients; automatically importing whichever client connects first would recreate the same ownership race. In multi-environment lists, each backend owns its own policy rather than one client silently mirroring writes to other environments.

This establishes the ownership boundary that overlaps with #5141. Its proposed additional auto-settle controls should extend the server-owned policy rather than introducing separate web and mobile preferences.

UI Changes

No layout or interaction changes. The existing Beta setting now updates the primary environment and is read-only against older servers that do not advertise policy updates, so screenshots/video are not applicable.

Verification

• vp test run packages/contracts/src/settings.test.ts apps/server/src/serverSettings.test.ts packages/client-runtime/src/state/threadSettled.test.ts apps/mobile/src/features/threads/threadListV2.test.ts — 269 passed
• targeted typechecks for contracts, client runtime, server, web, and mobile
• targeted lint and formatting checks for all changed source and documentation files
• git diff --check

Checklist

• This PR is small and focused
• I explained what changed and why
• Screenshots are not applicable because there is no visual layout change
• A video is not applicable because there is no animation or timing interaction change

Model: GPT-5.6-Sol | Harness: Codex in T3 Code

---

Note

Medium Risk
Changes thread list classification and settings ownership across web, mobile, and server; behavior is gated by capability flags and defaults, but policy edits immediately affect all connected clients for that environment.

Overview
Moves the inactivity auto-settle threshold from per-device client settings into server-owned ServerSettings.threadSettlement, so web, desktop, and mobile classify threads the same way when connected to an environment.

Web sidebar v2 and chat settled state now read autoSettleAfterDays from each thread’s environment server config (not sidebarAutoSettleAfterDays). Mobile thread list v2 passes a per-environment map into buildThreadListV2Items instead of a hard-coded three-day default. Settings → Beta updates the primary environment via updatePrimarySettings and is disabled when the server lacks threadSettlementPolicy.

Contracts add ThreadSettlementSettings, rename settle-day bounds to shared THREAD_AUTO_SETTLE_* constants, and keep the legacy client field for downgrade compatibility. The server advertises threadSettlementPolicy: true and persists policy patches to settings.json. Inactivity settlement remains a derived list view only—no new thread.settle automation on the server.

^{Reviewed by Cursor Bugbot for commit cb360a6. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Move thread auto-settle policy from client settings to server-side environment config

• Adds threadSettlement.autoSettleAfterDays to ServerSettings and a threadSettlementPolicy capability flag to environment descriptors, replacing the legacy sidebarAutoSettleAfterDays client preference.
• Updates thread classification in both web (SidebarV2.tsx) and mobile (threadListV2.ts) to resolve the inactivity policy per-environment from server config instead of a single client default.
• The Beta settings panel now reads and writes the primary environment's server-side policy; controls are disabled when the server doesn't advertise the threadSettlementPolicy capability.
• Setting autoSettleAfterDays to null disables auto-settlement for that environment; missing entries fall back to DEFAULT_THREAD_AUTO_SETTLE_AFTER_DAYS (3 days).
• Behavioral Change: threads that were previously classified as settled using a client-local preference will now use the server-configured value, which may differ across environments.

^{Macroscope summarized cb360a6.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 94056ede-b423-465b-8a2c-a7154e84e7b6

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR fundamentally changes where the auto-settle policy is stored and read from (client → server), affecting how threads are classified across all connected clients. While backward compatibility is maintained, this architectural shift in configuration control is a significant behavioral change that warrants human review.

^{You can customize Macroscope's approvability policy. Learn more.}