CAA: accept recheck, the recovery path the bot already advertises

[rowan-claude]

The CAA bot ends every "please sign" comment with:

_{You can retrigger this bot by commenting recheck in this Pull Request.}

Commenting recheck does nothing. It has never done anything, in any repo in
this org.

Why

suggest-recheck is an input on contributor-assistant/github-action and it
defaults to true (action.yml), so the sentence above is appended to the
comment unless we turn it off. We never set the input, so it is on.

But the action has no recheck handling of its own — src/main.ts just calls
setupClaCheck(). recheck works purely by starting the workflow again: the
action re-reads the PR's commit authors and re-scans the comments, and the
verdict comes out different because the ledger has changed since last time. So
whether recheck works is decided entirely by our step gate, and ours only ever
admitted the signature sentence:

if: >-
  github.event_name == 'pull_request_target' ||
  (github.event.issue.pull_request != null &&
  github.event.comment.body == 'I have read the CAA and I hereby sign it, ...')

A recheck comment matches nothing, so the step is not scheduled. A skipped
step produces no log and no annotation, so the contributor sees no run at all —
they just get silence from a bot that told them what to type. Upstream's own
README carries the clause we are missing (github-action/README.md:40).

Why this is worth fixing rather than switching the suggestion off

recheck is the only thing that re-evaluates an already-open pull request
without pushing a commit to it, and this setup produces that situation on
purpose:

• The ledger is org-wide. A contributor with two open PRs who signs on one
  leaves the other red. Nothing re-runs it.
• We record some signatures by hand. The companion PR documents exactly
  that: signatures posted on an issue, or carrying extra text, get appended to
  signatures/caa.json manually. Appending to the ledger fires no event in the
  library repo, so the red check stays red. recheck is the natural last step
  of that procedure — and it was the one step that did not work.

Setting suggest-recheck: false would make the docs honest, but it removes a
capability we have a live use for. So: fix the gate.

The change

if: >-
  github.event_name == 'pull_request_target' ||
  (github.event.issue.pull_request != null &&
  (github.event.comment.body == 'I have read the CAA and I hereby sign it, ...' ||
  github.event.comment.body == 'recheck'))

Two details:

• recheck sits inside the github.event.issue.pull_request != null guard,
  so it cannot reintroduce the issue-thread crash this branch's parent PR fixes.
• Matched with ==, not contains. The bot's own comment contains the word
  recheck; a substring test would have the workflow retrigger on its own
  output.

Also documents recheck in the header, including one case it quietly recovers:
the action compares body.trim().toLowerCase() against the sign comment, while
the gate is exact, so a signature differing only in capitalisation or
surrounding whitespace satisfies the action but never reaches it. Today that
signature is lost silently — it does not even trip the manual-recording warning,
whose contains check is case-sensitive. With recheck reachable, the
contributor can recover it themselves.

Behaviour

Simulated over the representative events; issuefix is this PR's base branch.

event	before (main)	base branch	this PR	warns
PR opened	run	run	run	—
exact signature on a PR	run	run	run	—
recheck on a PR	skip	skip	run	—
recheck on a plain issue	skip	skip	skip	—
signature on a plain issue	run (crashes)	skip	skip	warn
signature + extra text on a PR	skip	skip	skip	warn
bot's own suggestion comment	skip	skip	skip	—
case-variant signature on a PR	skip	skip	skip	—
unrelated chatter on a PR	skip	skip	skip	—

Exactly one row changes against the base branch. Everything else is untouched.

Verification

• Read the action at v2.6.1 (the repo is archived; v2.6.1, 2024-09-26, is
  its final release). Confirmed suggest-recheck defaults to true in
  action.yml, that the suggestion is appended in
  src/pullrequest/pullRequestCommentContent.ts:99, and that no recheck
  handling exists anywhere in src/ — the string appears only in that comment
  text and in the README's example gate.
• Searched every comment in the org: zero recheck comments have ever been
  posted, so nothing regressed — the path was simply never exercised. (Control:
  the same search finds 6 threads containing the signature sentence.)
• Checked cla.yml run history across all repos. No run has ever been triggered
  by a recheck comment.

Relationship to the issue-thread fix

This was opened stacked on fix/caa-workflow-issue-comments, which rewrites this
same if: expression and this same file header. That branch has since been
squash-merged, so this is now rebased directly onto main and contains a single
commit. The recheck clause sits inside the pull-request guard that branch
introduced, so the two changes compose rather than collide.

🤖 Generated with Claude Code

---

Supersedes #163, which was opened stacked on fix/caa-workflow-issue-comments and
was auto-closed when that branch merged and was deleted. Same commit, rebased onto
main; GitHub will not let a closed PR be retargeted or reopened once its base
branch is gone.