ci: skip docs preview deploy for PRs from forks

[andreahlert]

Summary

The docs job in .github/workflows/docs.yml fails on every PR opened from a fork with the annotation:

Resource not accessible by integration

Root cause: for PRs from forks, GitHub provides a read-only GITHUB_TOKEN regardless of the permissions: block declared in the workflow. The peaceiris/actions-gh-pages step that publishes the preview to the gh-pages branch therefore fails, and the comment-progress steps also fail to write PR comments.

This blocks merging contributor PRs (e.g. #623) because docs is a required status check — the only path forward today is admin override.

Changes

Gate the three steps that need write access on PRs from the upstream repo only:

• Comment on PR
• Build PR preview website
• Update comment

New if condition:

github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name == github.repository

Behaviour after change

• Push to main: unchanged — only Deploy to GitHub Pages runs.
• PR from a branch in apache/burr: unchanged — preview is built and deployed, comments posted.
• PR from a fork: Sphinx build still validates docs; the three deploy/comment steps are skipped; job ends successfully.

How I tested this

• Verified the failure mode on #623 (annotation points at the peaceiris/actions-gh-pages step at line 67).
• Confirmed via gh api that recent docs runs on fork PRs are startup_failure/failure while runs on main succeed.
• Manually traced each if: expression: for push to main, github.event_name == 'pull_request' evaluates false, leaving the existing Deploy to GitHub Pages step (gated on push to main) as the only active deploy step.

Notes

This only restores the previous level of preview coverage for in-repo PRs; it does not attempt to enable previews for forks (that would require pull_request_target and a careful audit of the checkout/build steps to avoid running untrusted PR code with elevated permissions).

Checklist

• PR has an informative and human-readable title
• Changes are limited to a single goal
• Code passed the pre-commit check
• Any change in functionality is tested
• New functions are documented
• Placeholder code is flagged
• Project documentation has been updated if adding/changing functionality