[Feature]: Recurring/standing threads as a first-class kind — the Done/settle/unread lifecycle assumes every thread terminates

[iamtoled]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/web

Problem or use case

The thread lifecycle assumes a thread is a problem that gets solved and reaches a terminal state: work happens, the agent finishes, the thread is Done, it settles, it leaves the inbox. That fits task threads well.

But a large class of threads are standing sessions tied to an ongoing responsibility rather than a fix — a triage session I return to for days, an ops thread, a release thread, a research log, a recurring report. They are never "done"; they go quiet between bursts by design, and that quiet is their normal resting state, not a completion.

Why this matters

Every signal in the lifecycle misfires on them:

• Auto-settle files them away as finished (inactivity, or a PR association they never asked for — see [Bug]: Opening a release PR (dev → main) retroactively adopts every thread on the shared branch — all settled threads wake up stamped with the new PR number #5514).
• The "Done" + unread highlight, genuinely useful on a task thread where it means "the agent finished, your turn", is permanently lit on a standing thread — because waiting for me is its resting state rather than a transient handoff.
• Un-settling is the only recourse, and it doesn't stick ([Feature]: Durable per-thread "never settle" pin — the existing "active" override is cleared by activity, so no thread can be kept permanently active #5575).

The net effect: the states that carry information on task threads carry none on standing ones, and the signal degrades across the whole sidebar — which is where the product's value is concentrated when you run many threads.

Proposed solution

Model a standing/recurring thread as its own kind (a per-thread mode, not a new object): its resting state is "idle, as expected" rather than "done"; it is exempt from every auto-settle trigger; it does not raise the unread/Done affordance merely because the last turn ended. Ordinary task threads keep today's behavior unchanged.

Smallest useful scope

The durable keep-active pin already requested in #5575, plus suppressing the Done/unread completion signal for pinned threads.

Alternatives considered

Manually un-settling forever (doesn't stick); archiving standing threads between uses (loses them from view, and the context is exactly what makes them valuable); a separate project per standing thread (heavy, and doesn't change the lifecycle).

Risks or tradeoffs

A second thread kind is real product surface, and a thread exempt from settling can accumulate silently if the user forgets it — so the pin should be visible on the row, and removable in one action.

[jvitormelo]

+1. My standing threads are the ones bound to recurring schedule_task runs (error triage, scraping health checks, a focus reminder). They never finish by design, so I keep them pinned to stop them from mixing with task threads. A first-class standing kind (or the Automations section in #18039) would give them a proper home.