fix(release): grant pull-requests:read so the notes step stops 403ing

[eaitbrahim]

The failure

The v0.2.0 release run failed at Compose release notes (run):

repos/.../commits/<sha>/pulls → 403 "Resource not accessible by integration"
… then: Get "repos/.../pulls/{"message":"Resource not accessible…}" : unsupported protocol scheme ""

Root cause

The step reads merged PRs via gh api .../commits/<sha>/pulls and .../pulls/<n>, which require pull-requests: read. The workflow only granted contents: write, so the default GITHUB_TOKEN was denied (403). The 403 error body then got written into the PR-number list and fed back into a URL, producing the unsupported protocol scheme crash.

Fix

• Add pull-requests: read to permissions (the root cause).
• Defense-in-depth: only append bare numeric PR numbers to the list, and skip any non-numeric entry when fetching — so a future API hiccup can't crash the notes step the same way.

YAML validated locally. No code paths touched — workflow only.

⚠️ Recovery needed before re-running (the tag already exists)

The failed run's Tag step already pushed v0.2.0 (at the #147 merge commit), but no Release was published (the notes step died first). The workflow's own "tag already exists — immutable" guard will block a re-run until the orphan tag is deleted:

git push origin --delete v0.2.0     # remove the orphan tag (no Release was published)
git tag -d v0.2.0                    # local, if present

Then, after merging this PR, re-run the release workflow (workflow_dispatch, version 0.2.0).

🤖 Generated with Claude Code