code-review plugin: step 1(d) eligibility check has no SHA comparison — a stale prior review permanently exempts a PR from ever being reviewed again

## Summary

`commands/code-review.md` step 1(d) instructs the eligibility sub-agent to skip review
when the PR "already has a code review from you from earlier." There is no instruction
to compare that earlier review's target commit against the PR's *current* head. In
practice, a Haiku agent applying this literally treats any prior `### Code review`
comment — however old, however many commits have landed since — as permanent grounds to
decline. Once a PR gets one review, it silently stops getting reviewed on every
subsequent push, forever, with no error and no comment posted.

This is related to, but distinct from, #1700 (eligibility sub-agent inspects the wrong
PR entirely via `gh pr list`). This report is about the *correct* PR being inspected,
but the "already reviewed" clause itself lacking a recency/SHA check.

## Reproduction (observed in production, not synthetic)

We run `/code-review:code-review /pull/` headlessly from a CI gate whenever a
PR's tests go green (a merge-safety requirement — no merge without review). Two real
examples from our repo:

1. A PR received a real review on 2026-06-29/06-30 (issues found, fixed, `### Code
review` comment posted). 45 more commits landed over the following ~2.5 months.
7 separate automated re-review attempts against 7 different, never-before-reviewed
commits all returned a clean exit with no comment — including one attempt against a
commit that a human, running the same command manually, immediately found introduced
a serious tenant-isolation regression. The automated eligibility check never
flagged it because it saw the June comment and stopped there.
2. A different PR's review found and posted 2 real issues (`Found 2 issues: ...`) on one
commit. The very next commit (a merge bringing in unrelated upstream changes, not a
fix for those 2 issues) went through review again — the eligibility check saw the
just-posted `Found 2 issues` comment and treated it as "already reviewed," declining
silently. The PR merged on that commit with the 2 flagged issues never re-verified as
fixed or not.

## Expected

Step 1(d) should compare the date of the most recent existing `### Code review` comment
(or PR review) against the date of the PR's current head commit (`gh pr view --json
headRefOid,commits`, or `gh api repos///commits/`). Only decline as
"already reviewed" if no commit postdates that comment. This mirrors the fix already
suggested in #1700 for the PR-targeting half of step 1 — the same step needs the
equivalent fix for its "already reviewed" clause.

## Our workaround

We can't edit the shipped plugin prompt in-repo, so we're overriding it at the call site
via the CLI-invocation prompt itself (prepending explicit override instructions before
the `/code-review:code-review` reference), the same pattern #1700's reporter used to pin
`PR_NUMBER`. It works, but like that report says, it feels like a workaround for
something that should be the plugin's default behavior.

## Environment

- Plugin: `code-review@claude-plugins-official`
- Invocation: `claude -p "/code-review:code-review //pull/" --dangerously-skip-permissions`, headless, from a CI gate script (not GitHub Actions)
- Observed: 2026-09-06 through 2026-09-11

Read commands/code-review.md, starting at eligibility step 1(d), and inspect how it identifies an earlier `### Code review` comment and the PR's current head. Use the reported `gh pr view --json headRefOid,commits` or GitHub commit API details as the reference; done means a prior review prevents another review only when no newer commit follows it.

Escrita pelo modelo de indexação a partir do texto da issue.