Closes #184

Renaming a git-wt worktree previously required several manual steps:
`git branch -m`, `git worktree move`, cleaning up empty parent directories
left behind when branch names contain `/`, and re-`cd`-ing if invoked from
inside the renamed worktree. This adds a single-step rename that completes
the create/switch/delete vocabulary.

- `git wt -m <new>` renames the current worktree.
- `git wt -m <old> <new>` renames a specific worktree.
- `-M` is the force variant (overwrites existing target branch, allows
  moving a dirty worktree).
- Default branch is protected by `--allow-delete-default`, consistent with
  how `-d`/`-D` behave.
- Empty intermediate basedir directories (e.g. `.wt/feat/` after renaming
  `feat/foo` to `flat`) are cleaned up, including the `.gitignore` and
  `README.md` decoration files that initBaseDir plants in each one.
- Detached HEAD worktrees and the main working tree cannot be renamed.
- Shell integration: when the current worktree is renamed, the new path is
  printed on the last line so the shell wrapper `cd`s there. The wrappers
  now recognize `-m`/`-M` so `wt.nocd=create` still cds (rename targets an
  existing worktree at a new location, not a creation), matching the
  semantics agreed on in the issue.

- Drop the unused `git.MainRepoRoot(ctx)` call in `moveWorktree`; its
  error path was firing without the value ever being read.
- Harden `RemoveEmptyParents` against escaping basedir: the walk now
  refuses to start unless `startDir` is a strict descendant of
  `stopDir`, re-checks the relation after every step up, and only
  treats `.gitignore` / `README.md` as removable when their content is
  bit-identical to what `initBaseDir` wrote — so user-edited files in
  intermediate directories are no longer silently clobbered.
- Stop claiming `-M` "overwrites the target directory": `git worktree
  move --force` does NOT overwrite an existing destination, its
  `--force` only relaxes dirty/locked-worktree checks. The target-dir
  pre-flight now runs unconditionally; `-M` is documented as
  "overwrite existing branch, allow moving dirty/locked worktrees".
- Add `git.CheckBranchNameFormat` and call it before any filesystem
  work in `moveWorktree`. Previously an invalid new name like
  `foo..bar` would let `git worktree move` succeed and then leave the
  branch on the old name when `git branch -m` rejected the format.

Two Copilot-review findings on `-m`/`-M`:

- `moveWorktree` was calling `git.LoadConfig(ctx)` directly, which
  bypasses the `--basedir` / `--copyignored` / etc. flag-based overrides
  that `loadConfig(ctx, cmd)` applies. As a result `git wt --basedir
  ... -m ...` would compute paths against the wrong basedir and could
  also clean up the wrong tree on the way out. Switch to the same
  helper deleteWorktrees / handleWorktree use.
- The target-directory pre-flight assumed any existing `newPath` was a
  collision, but `newPath == oldPath` is a legitimate branch-only
  rename (e.g. a worktree created with `-b` whose directory is already
  named the new branch). Add a `samePath` guard that skips the
  collision check and the directory move when paths match, and
  surface non-`ENOENT` `os.Stat` errors instead of silently treating
  them as "does not exist".

Three Copilot-review findings on the previous fix:

- `newPath` was built via `git.WorktreePathFor`, which re-expands
  `cfg.BaseDir` without resolving symlinks. On macOS that left
  `newPath` at `/var/...` while `oldPath` (and the resolved `baseDir`)
  was at `/private/var/...`, silently breaking the `samePath` check.
  Build `newPath` off the already-symlink-resolved `baseDir` directly.
- When `--basedir` is overridden and the user queries by directory
  name (worktree created with `-b`, dir != branch),
  `git.FindWorktreeByBranchOrDir` failed to resolve because its
  basedir-relative match path uses internal `LoadConfig` and never
  sees the flag override. Add a fallback that retries the lookup with
  an absolute path under the already-resolved `baseDir`.
- `git.RemoveEmptyParents` documented "absolute paths required" but
  only `filepath.Clean`'d its inputs. A caller handing in a relative
  path could trigger deletions against cwd; enforce the precondition
  with an explicit error.

Match the style of the other git helpers in this package so any
explanation git emits about a malformed ref reaches the user. git
check-ref-format is silent today on the common failures, but the
suggestion costs nothing and future-proofs against new git output.

…fault)

The previous wording said `-m`/`-M` and "without worktree" deletion
were "blocked entirely", which contradicted the very next bullet that
documents `--allow-delete-default` as an override. Restructure the
note to lead with the override flag and describe each case as
"refused by default" instead.

The 1-arg form already blocked the main working tree via
rc.IsLinkedWorktree(), but the 2-arg form would resolve through
FindWorktreeByBranchOrDir to the main worktree (e.g. `git wt -m . new`
or by passing its path) and then defer the error to `git worktree
move`, which produces an opaque message. Add a post-resolve guard
that compares the resolved source path to MainRepoRoot and surfaces
the reason directly. E2E coverage added in
two_arg_rejects_main_working_tree (covering both the `.` path query
and the branch-name query with `--allow-delete-default`).

Two Copilot edge-case findings on the basedir cleanup logic:

- `isStrictDescendant` used `strings.HasPrefix(rel, \"..\")` to detect
  paths escaping the basedir, which also rejected legitimate child
  names beginning with two dots (e.g. `..cache`). Match only genuine
  parent traversals: `rel == \"..\"` or `rel` starting with `\"..\"` +
  the path separator.
- `onlyUntouchedDecorationFiles` relied on `DirEntry.IsDir()` to skip
  subdirectories, but symlinks report `IsDir()==false` regardless of
  their target. A symlink named `.gitignore` / `README.md` whose
  target's content matched would have been considered removable, and
  `os.RemoveAll` would follow the symlink semantics unpredictably.
  Treat any symlink in the directory as making it non-removable.

Two more Copilot findings:

- `RenameBranch` now passes branch names after `--` so a name
  beginning with `-` (e.g. `-q`) is not parsed as an option by
  `git branch`. `CheckBranchNameFormat` would accept such names, so
  without `--` the rename would fail later with a confusing error.
- The user-facing message in `moveWorktree` had a third case it
  didn't cover: when `samePath` is true (branch-only rename, e.g. a
  worktree created with `-b` whose directory already matches the new
  name), it still said "Renamed worktree to <path>" with `<path>`
  unchanged. Add a dedicated branch-only message so the output
  accurately reflects what happened.

`completeBranches` was suggesting refs (branches/tags) as the second
positional argument under `-m`/`-M`, but in rename mode the second
arg is the *new name* (free text), not a ref. Suggesting refs would
mislead users into picking an existing branch and then hitting the
"branch already exists (use -M to force)" pre-flight.

- Extend the start-point guard to also exclude `moveFlag` /
  `forceMoveFlag` so the suggestion path is skipped under rename.
- After the first positional arg is already in place under rename,
  return `ShellCompDirectiveNoFileComp` so the shell does not fall
  back to filename completion either.

Add two e2e subtests under TestE2E_MoveCurrentWorktree that pin the
shell-integration semantics the maintainer specified in #184's comment
thread:

- nocd_create_still_cds_on_rename: with `wt.nocd=create`, renaming the
  current worktree must still cd to the new path because rename
  targets an existing worktree at a new location, not a fresh
  creation. Covers bash/zsh/fish.
- nocd_flag_suppresses_cd_on_rename: `--nocd` always wins over
  `-m`/`-M`, mirroring the wrapper precedence (nocd_flag is checked
  before rename_flag). Covers bash/zsh/fish.