[BUG] Desktop reports failed conversation start while backend succeeds after slow worktree scan

Preflight Checklist

• [x] I searched existing issues for the exact error text and worktree/startup timing terms.
• [x] This is a single bug report.
• [x] This report contains no secrets, private source, or customer data.

What's Wrong?

Claude Code Desktop can show "Failed to start the conversation" even though the backend conversation is still starting and later runs successfully without any retry.

On a Windows workstation with a large managed worktree pool, one affected start took 5 minutes 46 seconds end to end. Desktop displayed the hard-failure state while the backend continued silently, produced the first assistant response, marked the chapter, and set the conversation title.

The app's own timing log localized the delay:

[CCD start-timing] preflight=5ms worktree=239808ms mcp=79ms init=87021ms first_assistant=4552ms

The worktree phase spent about 4 minutes scanning 139 reuse candidates. At the time, the repository had roughly 600 registered disposable worktrees. The main process also logged substantial event-loop stalls. Retrying can therefore create a second conversation while the supposedly failed first conversation is already completing headlessly.

Reducing the stale worktree estate improved the scan size, but the UI contract remains unsafe: a slow start is rendered as a terminal failure even when the backend is still alive and succeeds.

What Should Happen?

Desktop should distinguish a slow/in-progress start from a terminal failure. If its UI deadline expires while the backend is still working, it should keep showing progress or offer cancellation. It should not invite a retry unless the original start has actually been cancelled or failed.

Worktree-pool discovery should also avoid a multi-minute linear scan of large reuse-candidate estates, or at minimum report that phase as ongoing.

Steps to Reproduce

1. On Windows, use Claude Code Desktop with a repository that has a large managed worktree pool (hundreds of registered worktrees reproduced this).
2. Start a new local conversation.
3. Observe Desktop show "Failed to start the conversation" while startup is still running.
4. Wait several minutes without retrying.
5. Observe that the original conversation completes startup and has an assistant response/title despite the earlier failure UI.

Environment

• Claude Desktop: 1.21459.0
• Bundled Claude Code: 2.1.209
• OS: Microsoft Windows 11 Pro 10.0.26200, ARM64
• Regression status: unknown

Additional Information

The post-hoc process exit seen later was a user/app cleanup of the orphaned CLI, not the cause of the original delay. The key evidence is the start-timing breakdown above: worktree discovery and session initialization were still progressing after the UI had declared failure.