revert: undo PR checkout fork support and unique branch naming

[ashwin-ant]

Summary

Reverts changes from #931 and #851 to address the regression reported in #936.

• Reverts Fix/PR checkout branch name conflicts #931 (fix: use unique local branch names for PR checkout to avoid conflicts)
• Reverts Fix PR checkout to support fork PRs #851 (Fix PR checkout to support fork PRs)
• Simplifies setupBranch in src/github/operations/branch.ts to use headRefName directly instead of the pr-{number} local branch naming scheme

Test plan

• Verify PR checkout still works for same-repo PRs
• Verify the headRefName fetch/checkout approach works correctly
• Run bun test to confirm all unit tests pass

Changelog

No user-facing changes — this reverts internal PR checkout implementation details.

🤖 Generated with Claude Code (0% 1-shotted by claude)

[claude]

This reverts the pull/{entityNumber}/head:localBranchName refspec back to fetching branchName directly from origin. Since headRefName for a fork PR refers to a branch that only exists on the fork's remote (not on origin), this will fail for fork PRs with:

fatal: couldn't find remote ref <branch-name>

This is the exact bug that PR #851 originally fixed. If this is an intentional decision to drop fork PR support, it would be worth documenting that limitation (e.g., in the FAQ or a code comment here). If fork PRs are expected to work, this line should continue using the pull/{number}/head refspec.

[claude]

Code Review Summary

This is a clean, well-scoped revert that simplifies the PR checkout path. The code after the revert is readable and has no leftover artifacts. One significant functional concern:

Fork PR Support is Removed

The main issue is that this revert re-introduces the fork PR checkout failure that PR #851 originally fixed. The change from pull/{number}/head:pr-{number} refspec back to fetching headRefName directly will fail for any PR originating from a fork, since the fork branch name does not exist on origin. See inline comment for details.

If dropping fork support is intentional, consider adding a code comment noting this limitation. If fork PRs need to work, the pull/{number}/head refspec should be preserved (the unique local branch naming from #931 could still be reverted independently).

Other Observations

• Security: No concerns. validateBranchName() + execFileSync with array args provides adequate defense-in-depth against injection, even with user-controlled headRefName.
• Performance: No impact -- same number of git operations, same fetch depth logic.
• Tests: setupBranch has no unit test coverage (pre-existing gap, not introduced by this PR). The CLAUDE.md notes integration testing happens in a separate repo.