Exempt Claude Code's cloud-agent commit identity from the CLA gate

[JSv4]

Summary

• The CLAAssistant check (.github/workflows/cla.yml) failed on PR Deliver configured agent personas to the model (#2247) #2248 ("Committers of Pull Request number 2248 have to sign the CLA") because all 5 commits are authored by GitHub user claude — the identity Claude Code's cloud/background agent uses when it pushes directly to claude/* branches. That account has never signed and wasn't in the allowlist (previously dependabot[bot] only).
• Adds claude to the allowlist alongside dependabot[bot], with a comment explaining why: copyright in those commits vests in whoever directed the tool (the maintainer, who has already signed per signatures/version1/cla.json on cla-signatures), not in the automation account itself — it isn't a third party asserting authorship.
• CLA.md's "How to sign" section now documents both exemptions (previously only dependabot[bot] was exempted, and only in a YAML comment).
• Adds a changelog fragment per changelog.d/README.md.

This is the first Claude-cloud-agent PR to hit the gate since cla.yml was added in #2234 (2026-08-09) — earlier claude/*-branch PRs (#2229, #2218, ...) predate the workflow, so this was previously invisible.

Test plan

• python scripts/collate_changelog.py --check passes
• pre-commit run on changed files passes (yaml, changelog fragment validation)
• After merge: comment recheck on Deliver configured agent personas to the model (#2247) #2248 to re-trigger CLAAssistant via the issue_comment path (which reads the workflow from main) and confirm it turns green

[claude]

Review

Small, well-scoped config/docs change. I verified the core claim rather than taking it on faith: pulled PR #2248's commit authors via the API and confirmed the GitHub login is exactly claude ({"login":"claude","name":"Claude","email":"noreply@anthropic.com"}), so the allowlist entry added here (.github/workflows/cla.yml:53) will actually match. Worth calling out explicitly since this session's own git identity happens to be claude[bot] (bracket suffix) — a plausible off-by-suffix bug that would have silently no-opped the fix. Good thing the PR used the exact literal rather than a claude* wildcard, as the comment notes.

Code quality / correctness

• .github/workflows/cla.yml: allowlist: dependabot[bot],claude is the correct comma-separated syntax for contributor-assistant/github-action (confirmed the action in use via uses: contributor-assistant/github-action@...v2.6.1). No wildcard, so no risk of accidentally exempting an unrelated future claude-something bot account — nice defensive touch, and it's explicitly called out in the comment.
• The comment block is long for a one-line config change, but the length is justified here: this is a legal/compliance gate, and CLAUDE.md's own docs philosophy ("favor concise, pointer-based docs" but also "document the why for non-obvious constraints") supports spelling out the copyright-vesting rationale inline rather than leaving future maintainers to reverse-engineer it.
• Nice touch cross-referencing CLAUDE.md's "Never credit Claude" rule and clarifying it's a different identity/context (interactive session commit messages vs. the cloud-agent's own commit authorship) — avoids a reader wrongly concluding the two rules conflict.

Docs

• CLA.md's "How to sign" section update mirrors the workflow comment's rationale and is consistent with the actual allowlist contents. Good — previously only dependabot[bot] was documented (and only in a YAML comment), so this closes a real gap where the exemption policy wasn't discoverable from the CLA doc itself.

Changelog

• changelog.d/cla-allowlist-claude.changed.md follows the fragment convention (slug + .changed.md, bullet body, no header) per changelog.d/README.md.

Test coverage

• No automated test is feasible for a GitHub Actions allowlist value — this is inherently CI-config-level. The plan to recheck Deliver configured agent personas to the model (#2247) #2248 post-merge to confirm the gate actually turns green is the right verification and the PR appropriately leaves it as a follow-up checkbox rather than claiming it's already verified.

Minor/non-blocking

• Not a concrete risk given GitHub usernames are globally unique, but worth having in mind for the future: if the claude account is ever compromised or GitHub reassigns/renames identities, the allowlist trusts the literal string claude indefinitely. Not something to gate this PR on, just a reason to keep the allowlist list short and reviewed periodically (which the PR already does well by using exact names, not patterns).

No blocking issues found. LGTM.