refactor: streamline lint results handling in GitHub Actions workflow

[joshjohanning]

This pull request updates the linting workflow for README files by changing how lint results are handled and presented.

Before we posted a comment back to the PR, which was nice and great, but sadly this won't work with forks - duh.

Just using the status checks status themselves and the workflow job summary instead.

[Copilot]

Pull request overview

This pull request refactors the README linting workflow to improve compatibility with forked repositories by replacing PR comment posting with GitHub Actions job summaries. The change removes the complex artifact upload/download mechanism and the separate post-results job, opting instead for a simpler approach that displays lint results directly in the workflow job summary.

Changes:

• Removed artifact upload and download steps for lint results
• Removed the post-results job that posted sticky PR comments
• Added job summary steps to both lint-gh-cli-readme and lint-scripts-readme jobs to display results inline
• Simplified lint result file naming from specific names to generic lint-results.txt

Comments suppressed due to low confidence (1)

.github/workflows/lint-readme.yml:55

• The || true has been removed from the lint command, which means the step will now fail when the lint script exits with a non-zero status (when issues are found). However, the next step "Post lint results to job summary" depends on the lint results file being created.

The problem is that when the lint script fails (exit code 1 on line 205 of lint-readme.js), the entire step will fail and subsequent steps may not run as expected, even with if: always(). The set -o pipefail option will also cause the pipeline to fail if any command in the pipe fails.

Consider either:

1. Keeping the || true to ensure the step completes successfully while still capturing the lint results, or
2. Explicitly setting the step to continue on error using continue-on-error: true on the lint step, or
3. Handling the exit code explicitly with a trap or by capturing it in a variable

The current implementation will prevent the job summary from being properly populated when lint errors are found.

          node ./.github/scripts/lint-readme.js ./scripts '##' '# scripts' | tee lint-results.txt