CI: prevent gh-pages deploy race with force_orphan + concurrency

The v1.2.1 tag push and the same-commit main push triggered the
deploy-pages job twice in parallel. They both ran build-html
successfully, then both tried to push to gh-pages — one won, the
other got 'failed to push some refs (fetch first)'.

Two changes:

  1. force_orphan: true on the gh-pages action. Each deploy
     creates a fresh orphan commit instead of fetching and
     fast-forwarding. No fetch step means no fetch-first conflict.
  2. Separate concurrency group 'deploy-pages' for the deploy job
     (the build concurrency group is keyed on github.ref, so
     main + tag don't share a group there). Serializes deploys
     across all refs so future tag-and-main races also self-resolve.

This commit itself ships v1.2.1's content (including the new
Notice page) to Pages.

Author: DatanoiseTV

.github/workflows/build.yml

@@ -125,6 +125,12 @@ jobs:
     # Deploy on main pushes AND on v* tag pushes, so tagged releases
     # also refresh the live site instead of leaving it behind.
     if: github.event_name == 'push' && (github.ref == 'refs/heads/main' || startsWith(github.ref, 'refs/tags/v'))
+    # Separate from the build concurrency group: serialize deploys
+    # across all refs so a main-push and a tag-push of the same
+    # commit don't race for gh-pages.
+    concurrency:
+      group: deploy-pages
+      cancel-in-progress: false
     runs-on: ubuntu-latest
     steps:
       - name: Download HTML artifact
@@ -140,6 +146,10 @@ jobs:
           publish_dir:     ./site
           publish_branch:  gh-pages
           commit_message:  "deploy: ${{ github.sha }}"
+          # Always create a fresh orphan commit on gh-pages instead
+          # of trying to merge / fast-forward against whatever's there.
+          # Makes each deploy atomic and immune to concurrent pushes.
+          force_orphan:    true
 
   release:
     name: Create GitHub Release