feat(clients): add thread auto-settle modes

[davidhu2000]

Often times, I work on issues that will end up having multiple PRs, so I'm constantly having to unsettled threads after each PR. This change adds more customization on settle behavior.

Never, Inactivity, PR merge/close, and combined modes.

Default behavior is maintained as PR merge/close + Inactivity

Testing

• 6 focused test files, 272 tests passed
• targeted typechecks, lint, formatting, and whitespace checks passed before rebase
• focused tests passed again after rebasing onto latest upstream main

Generated by GPT-5.6 via the Codex harness.

Note

Add thread auto-settle modes (never, inactivity, PR merge/close, combined) to web and mobile

• Introduces ThreadAutoSettleMode to packages/contracts/src/settings.ts with four modes: never, inactivity, pull-request, and inactivity-or-pull-request. Previously only an inactivity day threshold existed.
• Updates effectiveSettled in packages/client-runtime/src/state/threadSettled.ts to accept a ThreadAutoSettlePolicy object instead of a raw day count, enabling PR-based and combined settling logic.
• Adds web settings UI (apps/web/src/components/settings/SettingsPanels.tsx) with a Select control for mode and a conditionally shown days slider; includes legacy migration from days-only settings via resolveClientThreadAutoSettleMode.
• Adds mobile settings UI (apps/mobile/src/features/settings/SettingsRouteScreen.tsx) with a ControlPillMenu for mode selection, stored device-locally in mobile preferences.
• All thread list and sidebar components on both platforms now consume the resolved policy, so settled/active partitioning reflects the chosen mode.
• Behavioral Change: PR-based auto-settle is now opt-in; existing users without a stored mode are migrated based on their current day threshold, but PR threads will no longer be auto-settled unless the mode includes PR.

^{Macroscope summarized 904dfc8.}

[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: bda496f7-5b60-43a3-829d-9fafb3fbeabc

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 introduces a new user-facing feature: configurable thread auto-settle modes across web and mobile. The changes modify core settling logic and add new settings UI, warranting human review for the new capability.

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

[nikuscs]

I believe this should get in, its a regression in some sense :\ at company they usually PR from develop to main, so any new threads at develop instantly auto-settle :p

[davidhu2000]

I believe this should get int, its a regression in some sense :\ at company they usually PR from develop to main, so any new threads at develop instantly auto-settle :p

hi @nikuscs, yeah, we work mainly from a single main branch. for my use case, i use the same thread to finish up an entire feature, and usually there are more than 1 PRs involved with the feature. For example, 1 PR for db migration, 1 PR to update the API, and a last PR to update the PR. So right now, each time a PR lands on main, the thread resolves, and i have to reopen. When there are a lot of threads going on, it can be hard to find

[davidhu2000]

looks like this was added in #5880 so closing this as not needed.