Serialise red-master runs

The design rests on there being exactly one open ci-red issue, and the
lookup that enforces that is a read followed by a write. Two watched
workflows can complete seconds apart -- the nightly's jobs finish together,
and a push can land mid-run -- so two red-master runs could each find no
open issue and each open one.

cancel-in-progress stays false on purpose: cancelling the earlier run would
drop a notification about a failure, which is the thing this workflow exists
to prevent.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PtAbQJuygzhHiveuCxCPnT

Author: 2 people

.github/workflows/red-master.yml

@@ -39,6 +39,19 @@ on:
 permissions:
   contents: read
 
+# Serialised, because the whole design rests on there being exactly one open
+# issue. Two watched workflows can finish seconds apart -- the nightly runs
+# `pinned` and `latest` together, and a push can land while one is running --
+# and two concurrent runs would each look for an open issue, each find none, and
+# each open one.
+#
+# cancel-in-progress is false, and explicitly so: cancelling the earlier run
+# would drop a notification about a failure, which is the one thing this
+# workflow exists to prevent.
+concurrency:
+  group: red-master
+  cancel-in-progress: false
+
 jobs:
   notify:
     name: "Track whether master is red"