#2558 Post the attestation validation result as a PR comment (Forgejo does not render step summaries)

Problem

In swamp-extensions, the validate-attestation job in .forgejo/workflows/ci.yml runs scripts/validate_attestation.ts. That script writes its result as markdown to $GITHUB_STEP_SUMMARY: the commit match, the gate, freshness, the config-integrity check for each pinned file, and the table of verification steps.

On GitHub that renders as a job summary. Forgejo Actions doesn't render step summaries, so the result only appears in the raw job log, as one escaped line (⚙ Summary - ## Attestation Validation\n\n✅ Commit matches…). To see why a PR's attestation passed or failed, a reviewer has to open the job log and read that line.

Proposal

Post the attestation validation result as a comment on the pull request, the same way the review-integrity job already posts its audit.

• One comment per PR, updated in place. Mark it with a hidden marker such as <!-- validate-attestation -->. On each run, update the existing marked comment instead of adding a new one, so a PR pushed ten times doesn't collect ten comments.
• Posted on every result: pass, fail, and a missing attestation. The failure cases matter most, because the comment should say which check failed and why.
• Name the commit in the comment, so a stale comment can't be mistaken for the current head's result.
• The comment never decides the verdict. Failing to post is a warning. The job's pass or fail still comes only from the validator.
• Keep writing $GITHUB_STEP_SUMMARY when it's set, so the script still works on GitHub-compatible runners.

Implementation notes

• The validator runs from the base commit, so a PR can't change its own judge. Any change to validate_attestation.ts takes effect for PRs opened after it merges.
• Keep the script free of any forge's comment API. A suggested split:
  • add a --summary-file <path> output to validate_attestation.ts;
  • add a separate workflow step, if: always(), that posts or updates the comment through the Forgejo API with secrets.BOT_TOKEN, as review-integrity does.
• The job needs pull-requests: write.
• Fork PRs get no secrets under pull_request. For them, skip the comment step with a log line rather than failing.
• The markdown comes from the attestation, which the PR author controls. Before posting, escape or strip anything that could break out of the table or the marker, such as HTML comments and pipes in step names.

Acceptance criteria

• A PR with a valid attestation gets one comment showing ✅ for commit, gate, freshness and each pinned file, plus the steps table.
• A PR with no attestation, or a failing one, gets a comment that names the failing check. The job still fails.
• Pushing again updates the same comment, now naming the new commit.
• A failure to post the comment doesn't change the job's result.
• A fork PR's job still validates, and skips the comment with a log line.