ci: restore Actions runner capacity for research validation stack

[Tristan-Stoltz-ERC]

Problem

The SYM-ARCH-002 validation stack is now blocked by execution capacity rather than known code/test failures.

Observed on 2026-08-25:

• repository-wide Actions state reached 89 queued runs / 0 in-progress runs;
• current research: add SYM-ARCH-002A experimental core #57 exact-head SYM-ARCH-002A Experimental Core remains queued with runner_id: 0;
• fresh research: add SYM-ARCH-002A2 hierarchical statistics and power planning #58/research: add SYM-ARCH-002A3 benchmark validity and mutation testing #59/research: add SYM-ARCH-002A6 online measurement dynamics #65 dedicated runs are also queued;
• GitHub public status reports Actions operational;
• the last successful ubuntu-latest Symthaea job waited roughly two hours for assignment before running successfully;
• a guarded probe using the repository's existing [self-hosted, gpu, nixos] labels also remained unassigned, indicating no matching self-hosted runner was online/available at that time.

This should be treated as an operational blocker, not as a failed research result.

Queue hygiene already landed

• normal CI already supersedes stale automatic runs;
• Showroom Integrity now supersedes stale branch/PR runs;
• SYM-ARCH-001 no longer launches the completed 16-seed campaign on unrelated psych-bench changes;
• research: add SYM-ARCH-002A experimental core #57 and current direct children research: add SYM-ARCH-002A2 hierarchical statistics and power planning #58/research: add SYM-ARCH-002A3 benchmark validity and mutation testing #59/research: add SYM-ARCH-002A6 online measurement dynamics #65 now have dedicated-workflow supersession concurrency.

These changes reduce future queue amplification but cannot retroactively cancel old runs created before the concurrency groups existed.

Diagnosis / checks

Organization owner should inspect:

Organization Settings → Actions → Runners → GitHub-hosted runners

and record:

1. active hosted jobs;
2. maximum hosted concurrency for the current plan;
3. whether the organization is at its concurrency ceiling;
4. any Actions billing/spending/policy restriction;
5. whether another Luminous Dynamics repository is consuming the available slots.

GitHub documents this view as the authoritative place to inspect active jobs, queued jobs, and maximum concurrency.

If the self-hosted fallback is intended to be real, also inspect the registered runner list and restore/register a runner carrying all three labels:

• self-hosted
• gpu
• nixos

No registration token or credential should ever be committed to the repository.

Acceptance criteria

This blocker is resolved when all are true:

• at least one current exact-head Symthaea hosted job receives a nonzero runner assignment and executes;
• research: add SYM-ARCH-002A experimental core #57's SYM-ARCH-002A Experimental Core exact-head workflow reaches a real conclusion;
• the effective organization concurrency ceiling/current usage is documented;
• if [self-hosted, gpu, nixos] remains an advertised fallback, at least one matching runner is confirmed online and capable of accepting a manual smoke job;
• queued state is not interpreted as PASS/FAIL scientific evidence.

Research boundary

Do not bypass #57's executable merge gate because of this issue. Runner unavailability is infrastructure state, not validation. Once execution capacity returns, #57 should be merged only if the frozen exact-head gate passes; otherwise fix only the observed defect.

[Tristan-Stoltz-ERC]

Queue-hygiene coverage is now complete for the active SYM-ARCH research stack. Dedicated workflows for #57/#58/#59/#60/#61/#62/#65/#66 all supersede stale automatic runs while keeping deliberate manual dispatches independent. The completed SYM-ARCH-001 campaign is also manual-only for full reproduction, and Showroom Integrity now supersedes stale branch/PR runs.

This means further queue growth should no longer be attributed to missing supersession in the active research workflows. Remaining blockage should be investigated at the organization/account runner-capacity layer described in this issue.

Current research policy remains unchanged: do not bypass #57's executable gate.