Add Settle + new thread to thread actions

[PookMook]

Problem

After finishing a thread, I usually want to settle it and immediately start the next one in the same place.

Today these are separate actions: settle the finished thread, open New task, then select the relevant environment and project again.

The missing menu item here is Settle + new thread. The Rust + Solid rewrite is, naturally, for the memes.

Proposal

Add Settle + new thread next to Settle in the thread action menu on mobile and web/desktop.

On an idle, settleable thread it would:

1. Settle the current thread.
2. Open a blank new-thread draft for the same environment and project.
3. Use the normal new-thread defaults for provider, model, mode, and worktree behavior.
4. Focus the composer.

If settling fails, stay on the current thread. If the thread is still running or has unresolved work, disable the action under the same rules as ordinary settlement.

This should not copy conversation context, create a handoff, or automatically send a prompt. It is only a shortcut from a completed thread to a blank new one.

Would this small cross-client action fit T3 Code?

[ChristianEllehammer]

+1, and I would like this as a bindable keybinding command too, not only a menu item. Something like thread.settleAndNew, next to thread.settle (mod+shift+s) and the new-thread commands, so finishing one thread and starting the next in the same project is a single keypress.

A few details that might make it easier to scope, from reading the current code and docs:

• How it differs from plain settle. Today, settling the thread you are looking at moves you forward to the next remaining card, and only opens a fresh draft when it was the last active one. This command would always land on a fresh draft in the same project. That landing spot is the whole difference.
• Which "new". It should behave like chat.newLocal (same environment and project as the thread, straight to the composer), not like chat.new, which opens the project picker when there are several projects.
• Order and failure. Open the draft only once the settle is accepted. If the thread cannot be settled, stay put and show the usual reason, as proposed above.
• Worktree. The draft should use the normal new-thread defaults and not reuse the settled thread's worktree, since a "run on settle" project action may be cleaning that worktree up.
• Already settled. thread.settle un-settles a settled thread. This command should not; on a settled thread it just opens the new draft.
• On a draft. Nothing to settle, so it does nothing.
• Undo. thread.undo un-settles the thread as it does today. The untouched empty draft does not need to count as a second undo step.
• Default key. None needed; a bindable command with no default would be enough.