ci(docs): serialise the pages deploy

Publishing the site force-pushes an orphan `pages` branch. Two runs racing can
therefore land out of order and leave `pages` holding the older build, with both
runs green and nothing to indicate the site went backwards.

A `pages-deploy` concurrency group with cancel-in-progress makes a newer push
cancel an older in-flight build rather than queue behind it, so the last push to
land is the one that ends up published.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.forgejo/workflows/docs.yml

@@ -14,6 +14,14 @@ on:
       - '.forgejo/workflows/docs.yml'
   workflow_dispatch: {}
 
+# Deploying is a force-push of an orphan branch, so two runs racing can land out
+# of order and leave `pages` holding the older build — the site would silently
+# go backwards with both runs green. Serialise them, and let a newer push cancel
+# an older one that is still building rather than queue behind it.
+concurrency:
+  group: pages-deploy
+  cancel-in-progress: true
+
 permissions:
   contents: write
 

changes/docs-deploy-concurrency.md

@@ -0,0 +1,7 @@
+bump: patch
+type: ci
+The docs deploy is serialised. Publishing is a force-push of an orphan `pages`
+branch, so two runs racing could land out of order and leave the site holding the
+older build — with both runs reporting success. A `pages-deploy` concurrency
+group with `cancel-in-progress` means a newer push cancels an older in-flight
+build instead of queueing behind it.