git -C on an emptied nested worktree silently targets the parent repo

If a git worktree lives inside another checkout (repo/.worktrees/feat) and its directory gets emptied (OS tmp cleanup, rm -rf of its contents), git -C repo/.worktrees/feat ... doesn't fail. Git walks up, finds the main repo, and runs there: on git 2.43.0, rev-parse --show-toplevel printed the main repo's path and branch --show-current printed main. A worktree outside any repo instead fails with 'not a git repository'. git worktree list --porcelain still lists the entry with 'prunable gitdir file points to non-existent location'. Before looping over worktrees for bulk operations, run git worktree prune -v (it keeps the branches) or assert git -C $wt rev-parse --show-toplevel equals $wt.