fix(ci): advisory reviewer could never comment on a fork PR (403)

[bkd-dotcom]

Rolls out Signetry/core#92, which was verified end to end in core before propagating here.

The bug

reviewer.yml runs on pull_request and requested pull-requests: write. On a PR from a fork, GitHub downgrades GITHUB_TOKEN to read-only regardless of the permissions: block — so the write grant was silently dropped and issues.createComment returned:

Resource not accessible by integration  (403)

Every outside contribution showed a red review check and never received the advisory comment it was supposed to get.

The fix

The standard trusted/untrusted split:

	trigger	token	runs PR code?
reviewer.yml	pull_request	no write perms	yes
reviewer-comment.yml	workflow_run	pull-requests: write	never

The untrusted job stages comment.md + the PR number as an artifact; the trusted job downloads it and posts. Because the trusted job never checks out, builds, or executes PR code, holding a writable token there is safe.

Why not pull_request_target: it's the one-line fix and it's the wrong one — it grants a writable token in the base repo's context, and checking out PR head code under it is a well-known RCE footgun. Not a trade a change-control product should make.

Second bug, fixed here too

Found while testing the first: the advisory step's trailing exit 0 had never run. GitHub invokes run: steps as bash -e, so set -uo pipefail doesn't clear errexit and any non-zero exit from the reviewer (i.e. a Block verdict) aborted the step before reaching it. That contradicted the workflow's own contract — "never blocks the PR" — by turning the check red.

Hardening

• PR number travels in the artifact (workflow_run.pull_requests is empty for forks) and is filtered to digits on both write and read.
• Comment body is passed to the API as data, never through a shell or eval.
• Body truncated at 65 000 chars (API limit 65 536).
• The poster only updates a marker-bearing comment authored by a Bot, so a contributor can't get the bot to overwrite a human's comment by planting the marker in a PR description.

Also

Bumps the signetry-reviewer pin to v0.2.0, which carries the fix for CI rules firing on YAML comments — the reviewer had been blocking PRs for documenting a risk in a comment.

Verification

actionlint clean on both files. The chain itself was proven in core: the Reviewer comment workflow fired on workflow_run, succeeded, and posted as github-actions[bot]; a real fork PR's review check went red → green.

One note: workflow_run workflows always load from the default branch, so the chain only completes for PRs opened after this merges (an existing PR needs a rebase to pick up the artifact-upload half). Not a problem, just the reason the fix can't retroactively fix in-flight PRs.