Suggested task ("task chip") intermittently fails to start, with no surfaced error and no log

## Summary

Clicking **Start with worktree** on a suggested task chip intermittently fails.
The only feedback is a toast reading `Couldn't start the suggested task.` There
is no error detail in the UI, and I could not find any log on disk that records
the underlying failure.

The intermittency is not the main complaint — **the absence of any diagnosable
error is.** When it happens there is nothing for the user to act on, so every
occurrence is a dead end.

## Environment

| | |
|---|---|
| Claude Code | 2.1.268 |
| Surface | Desktop app, Code tab |
| OS | macOS 15.7.4 (build 24G517), Darwin 24.6.0, Apple Silicon |
| git | 2.39.5 (Apple Git-154) |
| Model | Opus 5 |

## Steps to reproduce

Not reliably reproducible — it happens occasionally, across sessions.

1. In a session, have the assistant file a suggested task (a "chip") via the
task-suggestion tool.
2. Click **Start with worktree** on the chip.
3. Occasionally: the toast `Couldn't start the suggested task.` appears and no
session is created.

The chip that failed was filed from a session whose working directory was a
**git worktree** (`/.claude/worktrees/`) rather than the main
checkout. A re-filed chip that explicitly targeted the main checkout did start
successfully — but that attempt was also simply a *retry*, so I cannot
attribute the success to the directory. n=1 on each.

## Expected

Either the task starts, or the failure names a cause the user can act on
(permission, path, git state, disk, network), and the underlying error is
written somewhere inspectable.

## Actual

A single toast with no detail:

> ⚠ Couldn't start the suggested task.

No log found. I searched `~/Library/Logs` and `~/Library/Application Support`
for anything Claude-related modified around the failure and found nothing that
captured it.

## Causes ruled out

Worth recording so this isn't chased at the git layer — none of these is the
problem:

- **Creating a worktree from inside a worktree works.** `git worktree add` run
from a worktree returned exit 0.
- **So does a nested target.** `git worktree add` pointing *underneath* the
current worktree also returned exit 0.
- **No stale worktree registry.** `git worktree prune --dry-run` reported
nothing prunable, with 30 worktrees registered.
- **Not disk.** 487 GiB free.
- **Working tree was clean** at the time of the failure.

## What would help

1. Surface the underlying error in the toast, or behind a "details" affordance.
2. Write the failure to a log file with a documented location.
3. If the spawn has a precondition on the session's working directory being a
main checkout rather than a worktree, fail with that message explicitly —
or handle the worktree case.

I can supply the local session and task identifiers privately if they help
correlate telemetry; I have left them out here deliberately.

Start at the suggested-task tool and the Desktop app's “Start with worktree” action, then trace the path that produces the `Couldn't start the suggested task.` toast. Check how the underlying failure is handled and where application logs are written. Done means failures expose an actionable cause and are recorded at an inspectable location, while successful starts still work.

Written by the indexing model from the issue text.