[Feature]: Let an agent or tool mark a thread as waiting on outside work

[Luzivog]

Before submitting

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

Area

apps/server (contracts, orchestration) and apps/web (sidebar status). Seen on 0.0.43-nightly.20260924.2187.

Problem or use case

An agent often ends its turn while work it started keeps running outside the provider: a CI run, a deploy, a merge queue. The result comes back later as a message that starts the next turn (we send it with thread.turn.start from a watcher). In between, the sidebar shows the thread as Done or ready, so it looks finished when it isn't.

T3 already has the right state, Monitoring (backgroundLiveness: "monitoring"), but only a background task that the provider reports can set it:

• Claude Code background shells and Monitor tasks count. In our store, Claude threads opened about 27,000 background shell tasks in 14 days.
• Codex threads never get it. Over the same 14 days their only task rows were subagents (collabAgent/*), with no background terminals.
• Nothing outside the provider can set it. thread.activity.append is server-internal and is not in DispatchableClientOrchestrationCommand.

So the same wait shows Monitoring on one provider and Done on another, and a watcher that knows the thread is waiting has no way to say so.

Proposed solution

A client-dispatchable pair of commands, plus a matching tool on T3's MCP server next to link_pull_request, so that either the agent or an outside tool can open and close a wait:

• thread.wait.open { threadId, waitId, title, expiresAt? }
• thread.wait.close { threadId, waitId }

An open wait would count toward backgroundLiveness: "monitoring" (or a separate "Waiting" label), show in the task panel under its title, and hold auto-settle and completion notifications the way a background monitor does. expiresAt keeps a crashed tool from leaving a thread waiting forever.

Why this matters

Anyone who runs agents through CI, deploy or review loops has threads that end a turn and come back later. Today those threads read as finished, and whether they show Monitoring depends on which provider ran them rather than on whether work is still pending.

Smallest useful scope

The two commands, counted in backgroundLiveness, using the existing Monitoring label. The MCP tool and a task-panel row can come later.

Current workaround

We prefix the thread title with ⏳ through thread.meta.update and remove it when the result arrives. That sets titleState.source to manual, which stops title refinement, and it is a title rather than a status.

Related: #14016, #10929, #5476, #13625.