fix(ci): drop duplicate concurrency block from spark-theatre-gate caller (closes #438) (#439)

## Root cause

PR #379 (2026-05-27) added a workflow-level \`concurrency:\` block to
this caller as part of \"add concurrency blocks to 5 read-only
workflows\". The spark-theatre-gate reusable workflow in standards
**already** declares the same concurrency key, and \`\${{
github.workflow }}\` in a reusable resolves to the **caller's** workflow
name (per the estate-known reusable caller-context-vars semantics).

Stacking both blocks causes GitHub to reject the run at
workflow-creation time with a \`startup_failure\`. The Actions UI shows
the run as failed in ~2s, but no job ever spins up and no \`check_run\`
is ever emitted — so the required status-check context
\`spark-theatre-gate / SPARK Theatre Gate\` stays unsatisfied on every
PR.

## Empirical signature

| Window | Run conclusion |
|---|---|
| Before 2026-05-27 13:16Z (pre-#379) | \`success\` /
concurrency-\`cancelled\` |
| After 2026-05-27 13:16Z (post-#379) | \`failure\` /
\`startup_failure\`, \`run_duration_ms\` ≈ 2000, zero jobs |

This was the root cause of every affinescript PR sitting in
\`mergeStateStatus: BLOCKED\` despite all visible checks passing — and
of the 14-PR admin-merge sweep on 2026-05-28.

## Why my-lang etc. don't hit this

Other repos that call the same reusable (\`my-lang\`, \`echidna\`,
\`betlang\`, \`stapeln\`, …) don't have the workflow-level concurrency
block in their caller. Their runs succeed normally.

## Cross-reference

- Closes #438 (owner decision: Option B — wire up the workflow rather
than removing the required context).
- hypatia#376 (BP008 phantom-required-context detector + AM010
admin-merge eligibility) makes this class of failure visible estate-wide
going forward.
- The \`fix/spark-theatre-gate-startup-failure\` checkout was the rest
of #379's concurrency-block additions deliberately left in place; this
is the only one of the five wrappers that conflicts with a reusable's
own concurrency block.

## Test plan

- [x] Local diff inspected — only removes the workflow-level concurrency
block (5 lines + comment) and replaces it with a documented explanation
- [ ] After merge: verify the next spark-theatre-gate run produces a
non-empty job list and emits the required \`spark-theatre-gate / SPARK
Theatre Gate\` check_run
- [ ] After merge: verify a subsequent PR's \`mergeStateStatus\`
resolves to \`CLEAN\`/\`UNSTABLE\` (not \`BLOCKED\`) when all other
checks pass

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: hyperpolymath

.github/workflows/spark-theatre-gate.yml

@@ -13,11 +13,17 @@ on:
 permissions:
   contents: read
 
-# Actions concurrency pool. Applied only to read-only check workflows
-# (no publish/mutation), so cancelling a superseded run is always safe.
-concurrency:
-  group: ${{ github.workflow }}-${{ github.ref }}
-  cancel-in-progress: true
+# Note: NO workflow-level `concurrency:` block here. The reusable
+# workflow in standards already declares concurrency on the same key
+# (`${{ github.workflow }}-${{ github.ref }}` — which resolves to the
+# CALLER'S workflow name in reusables). Stacking both blocks causes
+# GitHub to reject the workflow at run-creation time with a
+# `startup_failure`, so no `check_run` is ever emitted and every PR's
+# required `spark-theatre-gate / SPARK Theatre Gate` context stays
+# unsatisfied. Empirically: PR #379 (2026-05-27) added this block; all
+# 410+ runs since have been `startup_failure`, blocking auto-merge
+# across the repo and forcing a 14-PR admin-merge sweep on
+# 2026-05-28. See hypatia#376 BP008 for the class-level detector.
 
 jobs:
   spark-theatre-gate: