ci: remove or implement spark-theatre-gate / SPARK Theatre Gate (phantom required context) #438

What

`main` branch protection lists `spark-theatre-gate / SPARK Theatre Gate` in `required_status_checks.contexts`, but no workflow in this repo emits a check_run with that name. Every PR's `mergeStateStatus` resolves to `BLOCKED` with all visible checks green, so `--auto` waits forever.

Confirmed via `gh api repos/hyperpolymath/affinescript/branches/main/protection` 2026-05-28 and cross-checked against the rollup of 6 recent open PRs (#427, #429, #430, #435, #436, #437) — none of them have a `spark-theatre-gate` entry in their status-check rollup.

Impact

The 2026-05-28 bindings sweep had to admin-merge 14 PRs (6 affinescript + 8 cross-repo) because auto-merge could not satisfy a context that never runs. Going forward, every auto-merge on this repo stalls until manual admin intervention.

Decision needed (owner)

Two viable resolutions:

Option A — remove the context

If `spark-theatre-gate / SPARK Theatre Gate` is no longer wanted (the workflow was never landed, or it was retired), drop it from required contexts:

```
gh api -X PATCH repos/hyperpolymath/affinescript/branches/main/protection/required_status_checks \
-F 'contexts[]=Hypatia Neurosymbolic Analysis' \
-F 'contexts[]=analyze (actions, none)' \
-F 'contexts[]=bench-visibility' \
-F 'contexts[]=coverage-visibility' \
-F 'contexts[]=enforce-lowercase-stdlib' \
-F 'contexts[]=governance / Code quality + docs' \
-F 'contexts[]=governance / Guix primary / Nix fallback policy' \
-F 'contexts[]=governance / Language / package anti-pattern policy' \
-F 'contexts[]=governance / Security policy checks' \
-F 'contexts[]=governance / Well-Known (RFC 9116 + RSR)' \
-F 'contexts[]=governance / Workflow security linter' \
-F 'contexts[]=lint' \
-F 'contexts[]=migration-assistant' \
-F 'contexts[]=semgrep'
```

Option B — wire up the workflow

If SPARK Theatre Gate is wanted, land a workflow whose job's `name:` is exactly `spark-theatre-gate / SPARK Theatre Gate` so it actually emits a check_run on PRs.

Related

• Detected as a class-level finding by hypatia#376 (BP008 rule + AM010 admin-eligibility), so future occurrences across the estate will surface in `sustainabot`'s budget-resume sweep without needing manual triage.