on large checkout drops runtime connection after creating git worktree (orphan leak)

## Summary
`orca worktree create` against a large repo checkout (~700MB, includes node_modules) fails with `runtime_unavailable` ("The Orca runtime closed the connection before responding") — but the git worktree has already been created by the time the connection drops, so every attempt leaks an orphan worktree that must be cleaned up by hand.

## Repro
```
orca worktree create --repo id: --name --no-parent --setup skip --json
# => {"ok": false, "error": {"code": "runtime_unavailable", "message": "The Orca runtime closed the connection before responding. Restart Orca and try again."}}
git worktree list # the new worktree IS present despite the error
```
Same command against a small repo (760KB) on the same host, same daemon, same runtime succeeds. `worktree list`, `worktree current`, `terminal create`, and orchestration dispatches all work normally throughout — only create-on-large-checkout drops.

## Environment
- Orca 1.4.200, daemon protocol v36, macOS arm64, local runtime (ready/reachable before and after)
- Large repo: ~702MB working copy with node_modules; small repo: 760KB

## Expected
Either the create completes, or it fails atomically (no git worktree left behind), or it fails with a specific error (timeout/scan budget) instead of a generic connection drop.

## Actual
- Connection drops mid-create, deterministically reproducible on the large repo.
- Orphan worktrees accumulate across retries; each removes cleanly afterwards with `orca worktree rm --force`, so removal paths are fine — only create is affected.

## Impact on automation
CLI/automation callers cannot distinguish this from a total failure and will retry, accumulating orphans. A bounded create with either atomic rollback or a distinct error code would let callers handle it safely.

Start with the `orca worktree create` CLI entry point and reproduce the failure using the large checkout described in the issue. Trace the create request through the runtime connection and worktree creation, then inspect how failures are reported and whether cleanup runs. Done means large-checkout failures do not leave orphan worktrees and callers receive a specific, actionable error.

Written by the indexing model from the issue text.