fix(worktree): resolve the removal path before git can suffix-match it

Git looks a `<worktree>` argument up by unique path suffix BEFORE it
resolves it as a path, so a relative name is not scoped to the repository
it is handed to. With a checkout registered at
`/tmp/elsewhere/repo-task-7`, `git worktree remove --force repo-task-7`
run from an unrelated repository deletes that one, uncommitted files
included — measured, and now pinned by a test that loses `precious.txt`
without this change. Folder paths are stored exactly as they were given,
so the argument was only ever as absolute as whoever made the folder.

Resolving it here also collapses the last gap between the two halves of
this function: git and `std::fs` now act on one directory that neither
can reinterpret.