fix(documentation): grant issues:write, serialise gh-pages, thread by default

[seabbs-bot]

Closes #47. Closes #60 (and #61, its duplicate, already closed). Closes #32.

Three independent faults, all in documentation.yml, so they land together.

1. The docs-preview comment 403s (#47)

Posting a comment on a PR is POST /repos/{owner}/{repo}/issues/{n}/comments — the issues API. The job had pull-requests: write, which does not reach it, so every PR that built its docs successfully then failed on the final step:

Resource not accessible by integration

Added issues: write. This is the failure mode where the whole job goes red after doing all its work, which is why it reads as a docs failure rather than a permissions one.

2. Concurrent previews lose the gh-pages push race (#60)

Every caller deploys to the same gh-pages branch with a plain git push, and nothing serialises them. Two docs builds finishing together and one goes red:

! [rejected]  HEAD -> gh-pages (fetch first)
error: failed to push some refs

Added a concurrency group keyed on github.repository, not github.ref. That distinction is the fix: the collision is between two different PRs in the same repo, so the usual ref-scoped group would put them in separate groups and never see it.

cancel-in-progress: false — each preview still has to be published, so these queue rather than supersede.

3. julia_num_threads defaulted to 1 (#32)

The docs builds that actually take time are the ones sampling MCMC chains and rendering plots, and both parallelise. Defaulting to a single thread meant the slow case stayed slow everywhere.

Defaults to auto. A build that must stay single-threaded to be reproducible can still pass '1', and the input description now says so.

Risk

auto is the only behavioural change for a build that currently passes. If any caller's docs are thread-sensitive in a way I have not seen, that surfaces as a docs build failing where it used to pass, and the fix is one input on that caller. The other two changes only affect runs that are already failing.

Every workflow in the repo still parses under yaml.safe_load.

This was opened by a bot. Please ping @seabbs for any questions.

[seabbs-review-bot]

This PR grants issues: write (needed because PR comments go through the Issues API, not covered by pull-requests: write), adds a repo-scoped concurrency group to serialise gh-pages pushes across PRs, and changes the default julia_num_threads from '1' to 'auto'. All three changes are correctly reasoned, match the existing benchmark-history.yml pattern for serialising branch deploys in this same repo, and the explanatory comments justify genuinely non-obvious GitHub Actions behaviour rather than narrating history. No bugs found.

_{Automated first pass by seabbs-review-bot (Claude sonnet), triggered by: first pass. Not a human review. Comment @seabbs-review-bot to ask for another pass: @seabbs any time, the author's agent once it has pushed changes. Add the no-review label to opt this PR out. Ping @seabbs with any questions.}

[seabbs-bot]

Re-checked the review-bot verdict independently. It found no bugs and I agree.

• issues: write is genuinely required. A PR comment is POST /repos/{owner}/{repo}/issues/{n}/comments, which pull-requests: write does not reach, and origin/main's documentation.yml:27-30 grants only contents, statuses and pull-requests write. Without it the job 403s at its last step after a successful build.
• The repository-keyed rather than ref-keyed concurrency group is right. The collision is between two different PRs pushing gh-pages in one repo, which a ref-scoped group would not see. cancel-in-progress: false is right too — each preview still has to be published.
• benchmark-history.yml in this repo already serialises branch deploys the same way, so this is the existing pattern rather than a new one.

gh pr view 63 reports MERGEABLE / CLEAN, and gh pr checks 63 reports no checks — this repo runs no CI on its own PRs, so that is expected, not a stall. No review threads open.

Ready to merge. Merging closes #47, #60 and #32 together. No conflict with #64, #65, #66 or #67 — none of them touches documentation.yml.

This was opened by a bot. Please ping @seabbs for any questions.