ci(contribution): switch trigger to pull_request_target so check fires on every PR

[ai-hpc]

Summary

Switches the Contribution / PR body checklist workflow trigger from pull_request to pull_request_target so the check fires on every PR — including PRs whose head branch was created before the workflow itself existed.

Fixes the user-reported "ci only check 5" symptom on PRs #78 / #83 / #87.

Changes

• .github/workflows/contribution.yml — on: pull_request: → on: pull_request_target:. Same event types (opened, edited, synchronize, reopened). Same branches: [main] filter. Added an inline rationale comment that calls out the security caveat and why it doesn't apply here.
• CHANGELOG.md — one-line addendum to the existing Unreleased entry explaining the trigger choice.

Real Behavior Proof

• I have built and run the affected code locally (or noted why I could not).
• I have verified the change end-to-end on Jetson hardware OR explained the equivalent verification path I used.

What I ran

Diagnosis path:

gh pr list --state open --limit 5 --json number,headRefOid --jq '.[] | "#\(.number) [\(.headRefOid[0:7])]"'
# PR #87 [a26a25a]: core: preserve genie runtime prompt context
# PR #83 [f6ccece]: fix(telegram): use AtomicU64 nonce ...
# PR #78 [6225417]: fix(telegram): spawn handle_update ...

for pr in 87 83 78; do
  gh pr view $pr --json statusCheckRollup --jq '[.statusCheckRollup[].name] | length, .'
done
# Each prints: 5  (and lists fmt / aarch64 / clippy / test / no-default-features only)
# — confirming "PR body checklist" is missing from all three.

Root cause: on: pull_request: resolves the workflow file from the PR's head ref. Those three PRs were opened before #88 landed, so their head refs don't contain .github/workflows/contribution.yml and the workflow never schedules.

pull_request_target reads the workflow file from the base ref instead. Once this lands on main, the check will appear on every existing PR the next time the PR is touched (push to head, edit body, reopen) — and on every new PR immediately. No rebase required on contributor branches.

What I observed

.github/workflows/contribution.yml diff is exactly one keyword change in the on: block plus a longer explanatory comment. The job body is unchanged — it still reads github.event.pull_request.body and never checks out the PR, so the well-known pull_request_target security caveat (untrusted code running with secret access) does not apply.

This PR itself will be the verification:

• If the Contribution / PR body checklist job runs and passes, the trigger is wired correctly.
• After merge, opening any of PRs fix(telegram): spawn handle_update so one chat does not stall others #78 / fix(telegram): use AtomicU64 nonce so concurrent voice handlers can't collide on /tmp (#82) #83 / core: preserve genie runtime prompt context #87 and pushing an empty git commit --allow-empty (or just editing the PR body) will cause the new check to appear on those PRs too.

Test plan

• CI on this PR shows Contribution / PR body checklist: SUCCESS.
• After merge, push or edit one of fix(telegram): spawn handle_update so one chat does not stall others #78 / fix(telegram): use AtomicU64 nonce so concurrent voice handlers can't collide on /tmp (#82) #83 / core: preserve genie runtime prompt context #87 — the check shows up as a 6th status with the right pass/fail verdict.

Notes for reviewers

• pull_request_target security caveat: this trigger runs in the context of the base branch, which means GitHub Actions grants it write access to secrets and GITHUB_TOKEN. The standard footgun is "workflow checks out PR code and runs it, exposing secrets to the contributor." This workflow does neither — actions/checkout is not used, no PR-controlled script is executed. The only PR-controlled data read is ${{ github.event.pull_request.body }} (used in a bash grep/awk pipeline, not eval'd as code) and ${{ github.event.pull_request.title }} (matched against a fixed glob allowlist). Both are safe to consume.
• permissions: block stays contents: read + pull-requests: read (no write), so even though pull_request_target could grant more, we don't ask for it.