ci(ssot): SSOT Configuration Compliance fails on every fork PR — the reporting step cannot comment with a read-only token #13825

Found while triaging PR #13720.

Problem

SSOT Configuration Compliance fails on every fork PR, regardless of whether the PR has any SSOT
violation. It fails in the reporting step, after the analysis has already succeeded:

RequestError [HttpError]: Resource not accessible by integration
  - https://docs.github.com/rest/issues/comments#create-an-issue-comment
##[error]Unhandled error: HttpError: Resource not accessible by integration

.github/workflows/ssot-coverage.yml:36-39 declares the right permissions:

permissions:
  contents: read
  issues: write
  pull-requests: write

They do not help. For pull_request events from a fork, GitHub issues a read-only GITHUB_TOKEN
irrespective of the permissions: block — that is the security model, not a misconfiguration. So
github.rest.issues.createComment at :153 cannot succeed and, because actions/github-script
propagates the rejection, the whole job goes red.

The guard at :93 is if: github.event_name == 'pull_request', which is exactly the case that
cannot comment.

Impact

An external contributor sees a red required-looking check that names SSOT compliance while their
change may have none. The signal is inverted: the analysis passed and the reporting failed, but the
job reports the reverse. It is also self-defeating — the population this check exists to guide is
the one that can never receive its comment.

Note the "Set job status" step at :157 already fails the job on real violations, so the comment
step's failure adds nothing but noise.

Proposed approach

Two independent fixes, both small:

1. Do not let reporting fail the analysis. Wrap the github-script body in try/catch (or add
   continue-on-error: true to that step). A comment is a convenience; the verdict is the "Set job
   status" step.
2. Skip the step when it cannot work. Add github.event.pull_request.head.repo.full_name == github.repository to the if:, so fork PRs do not attempt it at all — and log the summary to
   the job output instead, where a fork contributor can still read it.

There is a working precedent in this repo: ci-dispatch-watchdog.yml skips its token-capability
probe on fork PRs for exactly this reason, with the reasoning written at the guard.

Acceptance criteria

• A fork PR with zero SSOT violations produces a green SSOT Configuration Compliance
• A fork PR with violations still fails, via the "Set job status" step
• The violation summary is visible to a fork contributor somewhere they can read it
• Every other github-script step that comments on a PR is audited for the same pattern

Related

Same class as the fork-token constraint behind the run-parking work (#13791, PR #13793).