Pop a delegated child thread out to top level

[colonelpanic8]

Sometimes a delegated child (a delegate_task subagent thread) turns into work I want to keep going myself. It already has the context, the worktree, and a live provider session, but it stays tied to its parent. It doesn't get a sidebar row, my follow-ups in it report back to the parent agent, and the parent's Stop and settle still reach it. Today the only way to keep it visible is pinning, and pinning a subagent thread succeeds without any visible effect (#31787).

Proposal

Add a Pop out to top level action for a delegated child thread, so it becomes an ordinary thread in place.

• Where: the thread menu in the chat header when viewing a child, and the child's row in the parent's Agents/Lineage panel. Agents get the same action on t3_thread_organize (pop_out), but a thread can't pop itself out, so a child can't escape its parent's control on its own.
• What it keeps: the same thread id, history, provider session, model, and folder or worktree. Nothing is copied or forked.
• What changes: the thread's lineage becomes top-level (parentThreadId: null, relationshipToParent: null), with an optional detachedFrom field recording the old parent. So the thread gets a sidebar row, can be pinned and settled like any other thread, and its later turns no longer report to the parent. The parent's Stop and settle no longer reach it. The parent's Lineage panel still lists it as "popped out" instead of dropping it silently.
• When it's allowed: only after the child's delegated task has finished and its result has reached the parent. While the task is still running, the action is disabled with a hint to wait or stop it first. That keeps the first version clear of the hard part, which is deciding who gets an in-flight task's result. Threads nested under the child move with it.
• Out of scope: provider-native subagents such as Claude's Agent tool. They can't take messages, so there's nothing to continue. Reattaching is also left for later.

Relation to #31157

#31157 proposes nesting child threads in the sidebar. A comment there describes a fork with detach/reattach as part of a larger nesting and grouping change. This proposal is just the detach half, on its own and independent of how the sidebar ends up showing children, so it could land first and the nesting work could build on it.

I have an implementation in progress against main and will link the PR here. A yes or no on the direction and the "finished tasks only" restriction would help.

[colonelpanic8]

Implementation is up in #34236: server command and event, t3_thread_organize pop_out, a thread-menu item and a Lineage panel button, with the "finished tasks only" restriction described above.