Stop concurrent JavaDoc runs racing to push gh-pages

[arpitjain099]

Fixes #85.

I do not think this is GitHub being flaky. The error is specifically a ref-lock rejection:

! [remote rejected] gh-pages -> gh-pages (cannot lock ref 'refs/heads/gh-pages':
  is at 41bbb056... but expected f1458988...)

That is what git says when the branch moved between the pushing run's fetch and its push, i.e. something else pushed gh-pages in between. The only thing that pushes gh-pages here is this workflow, and it triggers on every push to main.

During a release, several commits land on main within seconds, so several docs runs are in flight at once and each one wants to publish. That is visible in the run history rather than being hypothetical. On 2026-07-18 four runs started at 06:55:00, 06:55:04, 06:55:11 and 06:55:18, each taking roughly 30 seconds, so all four overlapped:

06:55:00 -> 06:55:32  cf34bff
06:55:04 -> 06:55:34  171c7bf
06:55:11 -> 06:55:38  cb2a51a
06:55:18 -> 06:55:51  d67d7dd

The same shape appears on 2026-06-13 (four runs across 16:51:42 to 16:53:14) and 2026-06-28. It also explains "if the job is re-run, it tends to succeed": by then the other runs are done and there is nothing to race with.

Adding a concurrency group makes the runs queue instead of overlapping, so only one publish touches gh-pages at a time.

Two deliberate choices in it:

• cancel-in-progress: false, so a publish that has already started is allowed to finish rather than being cancelled part way through pushing.
• The group is ${{ github.workflow }} without github.ref. The output branch is gh-pages regardless of which ref triggered the run, so including the ref would let a workflow_dispatch from another ref race with a main push, which is the thing being fixed.

One caveat worth stating: I could not reproduce the failure, and the current run history shows no failed runs, because a re-run replaces the conclusion of the run it re-runs. So this rests on the error message and the overlapping timings above rather than on a red run I can point you at.

If this looks right, the same workflow appears in other spdx-java-* repositories and would have the same exposure. Happy to open the matching PRs, but I did not want to send a batch before this one is agreed.

[arpitjain099]

@bact please merge when you can.