fix(cmd): resolve main repo root for pool commands run inside a worktree

[thirdreplicator]

Problem

Running get, status, prune, init, or return (without a path) from inside a managed worktree resolves the wrong pool when the repository has no origin remote.

These commands used git rev-parse --show-toplevel, which inside a linked worktree returns the worktree's own path. ResolvePoolDir hashes the remote URL when one exists — masking the bug — but for remote-less repos it falls back to hashing the repo path, so the worktree path hashes to a brand-new pool name. The result right after a successful get:

❯ th get
🌳 Entered worktree at ~/.treehouse/mentor-fe65ca/2/mentor. Type 'exit' to return.
❯ th status
🌳 No worktrees in pool.

Each such invocation also litters ~/.treehouse with empty ghost pool directories, and get from inside a worktree creates real worktrees in a ghost pool that status/prune from the main repo never see.

destroy and return <path> already handled this correctly via FindMainRepoRootFrom (git-common-dir resolution).

Fix

• Add git.FindMainRepoRoot(), the cwd variant of FindMainRepoRootFrom, which resolves a linked worktree back to its owning repository.
• Route get, status, prune, init, and return's cwd fallback through it.
• Remove the now-unused git.FindRepoRoot.

Testing

• New e2e regression test TestCommandsInsideWorktreeUseMainRepoPool uses a remote-less repo (the existing fixtures all have an origin, which hides the bug). It fails on main with the exact reported symptom ("No worktrees in pool") and passes with this change. It also verifies get from inside a worktree acquires from the same pool and that no ghost pool directory appears.
• go test ./... green, go vet clean, GOOS=windows go build ./... OK.

🤖 Generated with Claude Code