Make quality snapshot comments safe for fork PRs

Problem

Pull requests from forks receive a read-only GITHUB_TOKEN, even when a pull_request workflow declares pull-requests: write. The performance and coverage workflows currently invoke marocchino/sticky-pull-request-comment before running their substantive work.

PR #521 reproduced the failure across all performance and coverage jobs:

• the workflow token had PullRequests: read and Secret source: None;
• the initial sticky-comment step failed with Resource not accessible by integration;
• normal benchmark/coverage steps were then skipped because the preceding step failed;
• always() upload/comparison steps ran without metrics.json or lcov.info, producing cascading snapshot failures; and
• the final sticky-comment step failed with the same permission error.

The regular build, test, lint, and environment jobs passed, confirming that this was a fork-permission failure rather than a problem with the action pins in PR #521.

Security constraint

Fork workflows must remain untrusted and read-only:

• do not grant fork pull requests write access or repository secrets;
• do not use pull_request_target to execute or otherwise consume untrusted pull-request code; and
• do not weaken the fail-closed behavior of the actual performance and coverage gates.

Tasks

• Detect fork pull requests before invoking PR-comment-writing actions.
• Skip both in-progress and final sticky-comment steps when the token cannot write, while allowing the benchmark/coverage work and snapshot comparisons to continue.
• Ensure comment publishing itself is non-gating: a comment API failure must not suppress or replace the underlying quality-gate result.
• Preserve sticky performance and coverage comments for same-repository pull requests.
• Keep reports available to fork contributors through job summaries and uploaded artifacts.
• Audit other pull_request workflows for write operations with the same fork-token assumption.

Acceptance criteria

• A fork PR runs the complete performance and coverage jobs using only a read-only token.
• Fork runs do not attempt to create or update PR comments and do not report Resource not accessible by integration.
• Performance or coverage regressions still fail their jobs for both fork and same-repository PRs.
• Missing or malformed benchmark/coverage output still fails closed.
• Same-repository PRs continue receiving sticky snapshot comments.
• Fork reports remain inspectable in the GitHub step summary and artifacts.
• The solution does not use pull_request_target, expose secrets, or grant write permissions to untrusted fork code.

Reproduction

• PR: #521
• Performance run: https://github.com/microsoft/python-environment-tools/actions/runs/31991321814
• Coverage run: https://github.com/microsoft/python-environment-tools/actions/runs/31991321855

从 performance 和 coverage pull_request 工作流开始，尤其关注其中的 in-progress 和 final marocchino/sticky-pull-request-comment 步骤。使用 PR #521 以及链接的 performance 和 coverage 运行来复现 fork token 失败。完成标准是 fork 作业以只读访问权限完成，同时 gates 仍保持 fail-closed，同一存储库中的评论继续正常工作，并且报告仍可在摘要和 artifacts 中获取。