chore: auto-assign pull request authors

[chaim0m]

Summary

• assign opened, reopened, or updated pull requests to their author
• use pull_request, least-privilege permissions, and per-PR concurrency
• update toshimaru/auto-author-assign to pinned v3.0.3 on Node 24
• rely on the action's default GitHub token
• enable weekly Dependabot checks for pinned GitHub Actions

Jira: https://doitintl.atlassian.net/browse/CMP-48958

Why

An assignee makes responsibility visible without manual setup. Fork authors without push access cannot be assigned, so the base-token pull_request_target trigger provided no benefit and has been removed.

This remains a small independent workflow by design: assignment and file labeling have separate ownership, failure modes, and rollback paths, matching the requested small-focused-PR policy.

Test methods

• parsed the workflow as YAML
• ran git diff --check
• verified the pinned SHA resolves to v3.0.3
• parsed .github/dependabot.yml and verified the GitHub Actions ecosystem configuration
• GitHub Actions assign-author check passed on this pull request

After merge, open a human-authored PR with no assignee and confirm the author is assigned.

Could this break things?

Risk: low. The workflow changes only PR assignment metadata, checks out no code, executes no PR-controlled scripts, and retains only contents: read plus pull-requests: write.

[apgiorgi]

Not exploitable as written, but the trigger is both unnecessary and useless for the one case that would justify it, and the pin will rot silently.

1. Drop pull_request_target (assign-pr-author.yml:4).

It's safe today — no actions/checkout, no run: blocks interpolating github.event.*, so there's no untrusted-code or script-injection path. The problem is precedent: this file grants pull-requests: write under a trigger that runs with the base repo's token on fork PRs. Any future edit that adds a checkout of github.event.pull_request.head.sha turns it into a PR-hijack vector.

And the justification doesn't hold on its own terms: GitHub only permits assignees with push access, so a fork PR's author can't be assigned regardless of trigger — the API silently drops them. pull_request_target buys nothing here. Every PR in recent history (#26 onward) is same-repo, where plain pull_request plus pull-requests: write works.

Switching also makes the workflow self-testing on its own PR. Under pull_request_target it can only be validated after merge to main, which the PR body concedes.

2. Stale pin on a deprecated runtime (assign-pr-author.yml:16). 5cd66f0 is v2.1.2, runs.using: node20. Current is v3.0.3 on node24 — v3.0.0's only functional change was the Node bump. There's no .github/dependabot.yml in this repo, so this pin will never be bumped automatically; it'll start warning, then break.

Nits

• SHA pin with no trailing # v2.1.2 comment — unreadable at a glance.
• Pinning style diverges from the rest of the repo (ci.yml:15,18,40 and sync-manifests.yml:79 all use mutable tags). Stricter is fine, just inconsistent.
• No concurrency: block, unlike release.yml:12. Negligible for opened/reopened.
• secrets.GITHUB_TOKEN is redundant — the action defaults to ${{ github.token }}, which is what post-release-verify.yml:37 uses.

On value: .github/CODEOWNERS:2 (* @apgiorgi) already auto-requests review, so the assignee is a second near-identical signal. No built-in GitHub setting duplicates this, so the workflow isn't redundant — it's just low-yield for a repo where two accounts author everything.

Broader point across #48/#50/#51: three separate files, three triggers, one concern, none self-testing. If we want any of this, one pr-hygiene.yml with three jobs is cheaper to maintain. Also worth noting CONTRIBUTING.md asks for an issue before a PR on repo-surface changes like this.

[chaim0m]

Addressed the security and maintenance findings: switched to pull_request, updated the pinned action to v3.0.3/Node 24 with a readable version comment, removed the redundant token input, and added per-PR concurrency. I kept assignment separate from labeling intentionally because the requested delivery policy is small, independently reviewable PRs with isolated rollback.

One deliberate non-change: I kept immutable full-SHA pinning and did not bundle Dependabot configuration. The pin is current; enabling recurring bot-authored updates is a separate repository policy and should be reviewed independently rather than smuggled into this focused workflow.

[chaim0m]

The final maintenance request is now addressed as well: .github/dependabot.yml checks pinned GitHub Actions weekly, so the immutable v3.0.3 pin will not silently age. The branch includes current main, YAML validation passes, and go test ./... / go vet ./... pass. Re-requesting review on the current head.