Read a merged pull request's range without creating a worktree

[sameera]

As a developer landing a small fix, I want the pull-request helper to report a merge range on its own, so that a command that needs only the range does not have to check out a worktree to get it.

Acceptance Criteria

• Given a merged pull request number, when the helper runs range --pr <N>, then it prints one JSON object carrying repo, base, and head, where base and head are full commit SHAs, and it exits 0.
• Given a pull request that is open, or closed without merging, when the helper runs range --pr <N>, then it exits non-zero with a named diagnostic and prints no range.
• Given the subcommand has completed, when the repository's worktree list is inspected, then no worktree was created and none was removed.
• Given a squash-merged pull request and a rebase-merged pull request, when the subcommand resolves each range, then the changed-file set implied by the resolved range matches the changed-file set the pull request reports.
• Given the existing preflight, open, and remove subcommands, when the new subcommand is added, then their behavior and output are unchanged.

Notes

Reuse the existing range derivation rather than writing a second one. That derivation already handles squash, merge-commit, and rebase merges, including the changed-file-set check for the ambiguous squash-against-rebase case.

The existing open --mode close path returns the range only as a side effect of checking out a worktree. This subcommand exists because the fix lane needs the range and has no use for the worktree.

story_type: system · size: S