code-review skill silently reviews the local diff instead of failing when given an unresolvable PR number

## Description

The built-in `code-review` skill accepts a PR number, branch name, or file path as its argument, per its own listed description ("Review the current diff, or a PR number/branch/path target..."). But its diff-gathering step only ever runs `git diff @{upstream}...HEAD` / `main...HEAD` / `HEAD~1` against whatever is currently checked out locally - there's no `gh pr checkout`/`gh pr diff` resolution step for a PR-number argument.

Given a bare PR number that doesn't correspond to any local ref (e.g. `/code-review 155`), the skill silently falls back to diffing the current local branch and reports the result as if it had reviewed the requested PR - no error, no warning that the wrong thing was reviewed.

## Reproduction

1. Have an unrelated local branch checked out (not the PR's branch).
2. Run `/code-review ` for a PR that isn't checked out locally.
3. The skill returns a full review, but of the local branch's diff, not the PR's actual diff.

## Impact

This is a silent failure mode that can produce a confidently-wrong review - I hit this reviewing PR #155 on a large monorepo: the skill reviewed a small, unrelated branch (`feature/steve/destroy-dev-appconfig-fix`) that happened to be checked out, and reported all 10 findings as if they were PR #155's. It took manually diffing the PR branch to catch the mismatch.

## Expected behavior

Given a PR-number-shaped argument, the skill should resolve it via `gh pr view`/`gh pr checkout`/`gh pr diff` first, and fail loudly (clear error, no review produced) if that resolution doesn't succeed - never silently substitute the local checkout's diff for the requested PR's diff.

## Workaround

I built a project-level wrapper skill that resolves the PR via `gh pr view` first and fails loudly before handing off to `code-review` with a proper branch-diff target. Happy to share the implementation if useful as a reference.