feat(pr): check a pull request out into a worktree of its own master
`pr checkout --worktree <path>` creates a `git worktree` there and applies the pull in it, leaving the caller's checkout on the branch it is on. That is the shape this project is actually worked in — contributors and agents live in `.claude/worktrees/`, so the checkout in front of you usually has a feature half-finished in it, and reviewing anybody's pull request meant stashing first. The dirty-tree refusal is not made on this path, and that is the point of the flag rather than a relaxation of the rule: `git am` writes into a tree this command just created, and nothing here reads, moves or writes the caller's working tree, index or HEAD. Verified — `git worktree add` does not touch it, and the fetch and the corroborating `git diff base...FETCH_HEAD` that still run in the original checkout are reads of refs and objects. Everything that made `pr checkout` correct is unchanged: the branch fetch and its diff-text corroboration, `--patch`, the stacked bottom-up apply, `--empty=keep`, `check-ref-format`, and a stopped `git am` left stopped — with its four ways out rewritten to name the tree they apply to. `--branch` composes with it, naming the branch the worktree is put on. A path that already holds something, or that is inside a different repo, is refused before the branch exists, since git checks the path only afterwards and leaves the branch behind. `git worktree` invocation moved to `clients/git/worktree.rs` per docs/module-layout.md, with `pr diff --interdiff`'s scratch worktree moved onto the same two functions.