fix(cla): store CLA signatures locally so the check can actually run - #5

The CLA check has never passed in this repo. .github/workflows/cla.yml sets remote-organization-name/remote-repository-name to this same repo, which switches contributor-assistant onto its remote-storage path — and that path calls getPATOctokit(), which fails the job outright when PERSONAL_ACCESS_TOKEN is absent (only GITHUB_TOKEN is provided, and the repo has no secrets). It happens inside getFileContent(), which runs unconditionally after the allowlist filter, so allowlisted maintainers fail too — the errors are Please add a personal access token… followed by Could not retrieve repository contents. Status: unknown.

All 12 pull_request_target runs since 2026-03-09 failed identically, across four branches and every author. Dropping the two inputs points the action at the current repo — the same destination — using GITHUB_TOKEN, and contents moves to write so it can create and update cla-signatures.json on main. workflow-templates/cla.yml is byte-identical and ships the same bug to any repo that adopts the org template, so it gets the same fix.

Because pull_request_target loads the workflow from the base branch, the cla check on this PR still runs the broken copy from main and will be red. After this merges, a recheck comment on #3 and #4 re-runs them against the fixed workflow and turns them green.

🤖 Generated with Claude Code