fix(switch): name the branch a failed worktree add leaves behind

[worktrunk-bot]

Problem

git worktree add -b <branch> writes the branch ref before it populates the
worktree, and unwinds only what it registered. A failure in between — an index
git can't write, leading directories it can't create — therefore ends with the
branch present and nothing checked out on it:

$ git worktree add -b feat ../blocker/sub master
Preparing worktree (new branch 'feat')
fatal: could not create leading directories of '../blocker/sub/.git': Not a directory
$ git branch
  feat
* master

wt switch --create reported only ✗ Failed to create worktree for <branch> from base main, so the leftover was invisible until the next
wt switch --create <branch> answered Branch <branch> already exists — which
reads as a fresh name collision rather than as fallout from the first failure.
That second error is what #4108 had to decode.

Solution

On a failed --create, failed_add_left_branch asks whether the branch is now
present with no worktree, and WorktreeCreationFailed gains a hint naming it
with both recoveries:

✗ Failed to create worktree for feature/auth from base main
 ┃ fatal: could not create leading directories
↳ Branch feature/auth was created before the failure, with no worktree; to delete it, run git branch -d -- feature/auth; to use it, run wt switch feature/auth

The issue proposed deleting the ref or falling through to the no-create path.
Neither is what this does, and the reasons are worth stating:

• Deleting it is the rollback Stop a failed fork PR switch from deleting the user's branch #3984 removed. That rollback's
  did-we-create-it reasoning was wrong once and force-deleted a branch wt had
  not created, taking commits only it held. CLAUDE.md's data-safety rule says
  the same thing generally — no implicit destructive side effects, cleanup is a
  separate action the user chooses. A hint costs nothing and leaves the choice
  where it belongs.
• Falling through would make --create silently adopt an existing branch,
  which hides a genuine name collision — the case the error is for.

The detection is read-only and runs only on the error path. The worktree lookup
goes through a fresh Repository, since repo cached its inventory before the
add ran. setup_fork_branch deliberately keeps the old behavior: its re-run is
wt switch pr:N, which adopts or prefixes the branch on its own terms, so
naming the ref would point at a recovery that isn't the one to take.

Testing

test_switch_create_names_branch_left_by_failed_worktree_add drives the whole
path: a worktree-path template pointing under a regular file makes git fail
exactly where it leaves the branch behind. It asserts the reproduction (branch
present, no worktree registered on it) and then the hint. With the new flag
forced off, it fails with the pre-change output — ✗ Failed to create worktree for stranded from base main and nothing else — which is the reporter's first
error verbatim.

snapshot_worktree_creation_failed_leftover_branch pins the rendered hint.
cargo test --lib, the switch and git_error_display integration suites, the
snapshot/output guards, and cargo clippy --all-targets are clean locally; one
pre-existing unrelated failure (copy::tests::test_copy_dir_recursive_does_not_count_a_non_regular_file,
which needs a FIFO the CI sandbox won't create) reproduces on an unmodified tree.

Closes #4108 — automated triage

[worktrunk-bot]

Data-safety surface, per Data-Loss Surface: Hold for Human Review in .claude/skills/running-tend/references/review-pr.md: this adds a copy-pasteable git branch -d -- <branch> to a user-facing hint in src/git/error.rs (the WorktreeCreationFailed arm). Nothing in wt runs it, and -d is the refusing variant — it declines an unmerged branch, so the branch created from an integrated base is the only thing it can remove. The rule still covers deletion commands a diff introduces for users to copy, so this needs a human sign-off rather than mine: requesting review from @max-sixty.