Stop advisory release-notes reminders from failing fork and Dependabot PRs

[Paul Lizer (paullizer)]

Summary

check-release-notes currently fails on every pull request opened from a fork or by Dependabot, even when release notes are present and correct.

The job ends with:

RequestError [HttpError]: Resource not accessible by integration
##[error]Unhandled error: HttpError: Resource not accessible by integration

Root cause

release-notes-check.yml has two advisory steps that post a reminder comment using actions/github-script:

• Post PR comment (when notes needed but missing)
• Post PR comment (when latest features likely needed but missing)

Pull requests from forks and from Dependabot run with a read-only GITHUB_TOKEN (Contents: read, Metadata: read, Packages: read), so issues.createComment returns 403 and the step — and therefore the whole job — fails.

This contradicts the workflow's own design. The Validate release notes update step deliberately exit 0s, with the comment:

# Exit with warning (non-zero) to flag the PR but not block it
# Change 'exit 0' to 'exit 1' below to make this a hard requirement

and the second reminder even describes itself as "an automated, non-blocking reminder". A 403 while posting an advisory comment should never turn the check red.

Observed impact

• Fix workspace shared file approval visibility and harden distroless runtime overlay packaging in Dockerfile #1414 (fork: Xeelee33/simplechat) — release notes were updated and two fix docs added, but the check still reported FAILURE. It failed on the Latest Features reminder step, because support_menu_config.py wasn't touched.
• build(deps): bump pypdf from 6.15.0 to 6.16.1 in /application/single_app #1372, build(deps): bump snowflake-connector-python from 3.18.0 to 3.18.1 in /application/single_app #1369 (Dependabot) — same failure.
• Add configurable DLP controls with optional Presidio endpoint support #917 (fork: zarg-dev/simplechat) — will hit the same thing.

The red check is pure noise, and it trains reviewers to ignore a check that is supposed to be meaningful.

What changed

• Marked both advisory comment steps continue-on-error: true, with a comment explaining the read-only-token behavior.
• Added functional_tests/test_release_notes_check_fork_permissions.py, which asserts the two comment steps are non-blocking and that Validate release notes update stays blocking, so the check keeps its value.

Behavior on same-repo pull requests is unchanged: the token has write access there, the reminder comment still posts.

Validation

• python functional_tests/test_release_notes_check_fork_permissions.py — 2/2 passed.
• Workflow YAML re-parsed with yaml.safe_load; all 8 steps intact, continue-on-error set on exactly the two comment steps.

Version bump

Not applicable — this is a CI workflow change with no application/ changes, matching the precedent set by #1338 (github-actions bumps across 12 workflow files, no config.py bump).

Note on required checks

check-release-notes is not a required status check in any ruleset — the Main ruleset requires only enforce-branch-flow — so this was never a hard block, just a persistently misleading signal.