fix(cla): accept the phrase the workflow tells contributors to comment

[ywatanabe1989]

The bug

cla.yml sets custom-notsigned-prcomment telling contributors:

Comment I have read and agree to the SciTeX CLA. to sign.

but does not set custom-pr-sign-comment — so the action still accepts only its own default, I have read the CLA Document and I hereby sign the CLA.

The instruction we publish is one the system rejects. A contributor who follows it exactly is told nothing happened, and the check sits stale-FAILURE with no way for them to discover why.

Evidence

Found by figrecipe on scitex-ai/figrecipe #319/#320 (external contributor dchaudhari7177): the contributor commented the quoted phrase on 2026-07-23 15:56, and both CLA Assistant runs that day concluded failure. This affects every repo calling the org-reusable workflow, not only figrecipe.

The fix

One input, byte-identical to the phrase already published, plus a comment tying the two strings together so a future edit to one is visibly an edit to both.

Verified before adding it that custom-pr-sign-comment is a real input on the pinned action (scitex-ai/github-action@114064a, action.yml line 31: "The signature to be committed in order to sign the CLA.") — so this is not a no-op key that would look like a fix without being one.

Blast radius

Org-wide, and deliberately so — that is where the wrong instruction lives. It changes only which phrase is accepted; already-recorded signatures in cla-signatures are untouched. Reversible by revert.

Not landing this unilaterally: figrecipe found it and asked to pair, so tagging them as reviewer.

🤖 Generated with Claude Code

[ywatanabe1989]

Reviewed — the fix is correct; recording sign-off here since GitHub blocks a formal approval (this PR and my review resolve to the same bot identity).

Verified line 24 is byte-identical to the instruction on line 14 (I have read and agree to the SciTeX CLA.), and that custom-pr-sign-comment is a real input on the pinned action @114064a — the check that separates this from a green-looking no-op. Binding the two strings as "one contract" in the comment is the right call.

Optional future hardening (not a blocker): they remain two literals that could drift; a YAML anchor would give SSoT-by-construction, but the instruction embeds the phrase mid-sentence so that means restructuring the notsigned message. Comment-binding is the pragmatic choice today.

Good to merge from my side. Once it lands I will handle the one-line re-comment note to the contributor on #318/#319/#320 — keeping contributor comms in one voice per the operator.