fix(ci): serialize E2E runs via repo-wide concurrency mutex

[TortoiseWolfe]

Summary

The E2E suite runs against the project's single Supabase Cloud instance with shared test users, shared conversation rows, and beforeAll cleanupOldMessages hooks in 11+ messaging spec files. Two concurrent CI runs against the same backend race each other and dogpile shared state, blowing the 60-min GitHub Actions job timeout.

Fix is one workflow file edit. No test code changes.

Root cause (verified on 2026-05-13)

• Run 25769955636 (main, post-fix(docker): pin pnpm version to honor package.json packageManager field #86 merge, started 00:14:46Z) had E2E (firefox-msg 1/1) cancelled at exactly 60 min.
• Run 25770068787 (PR docs(auth): #85 replace stale Supabase project ref with placeholder #88, started 00:18:07Z — 3 min later) was running in parallel against the same Supabase project.
• Direct DB query confirmed conversation 4105492f-1047-40ef-bd6e-411788850547 (the one in the cancelled main test's Step 8: Conversation ID: log line) was created at 00:21:55Z by PR docs(auth): #85 replace stale Supabase project ref with placeholder #88's run, not main's.
• Main's tests reused PR docs(auth): #85 replace stale Supabase project ref with placeholder #88's conversation (test code detects "Connection already exists / Conversation already exists" and skips creation), then watched PR docs(auth): #85 replace stale Supabase project ref with placeholder #88's cleanupOldMessages wipe the data on each of 11 spec boundaries.

Disproven hypotheses

Theory	Evidence against
Retry-heavy specific test (e.g. complete-user-workflow.spec.ts)	That test passed first-attempt at 00:49:26Z; cancel hit much later
Supabase rate limiting	auth.audit_log_entries empty for entire window (audit disabled, not 429s); health endpoint reports ACTIVE_HEALTHY for all services
Cumulative latency from one run's request volume	Two runs were in flight, not one

Diff

 concurrency:
-  group: e2e-${{ github.ref }}
-  cancel-in-progress: true
+  group: e2e-supabase-${{ github.repository }}
+  cancel-in-progress: false

Why both fields had to change:

• Just flipping cancel-in-progress wouldn't fix anything — the race is cross-branch (main vs PR), not within one branch.
• Just changing the group key without cancel-in-progress: false would let pushes mid-run abort each other and leave Supabase in a half-cleaned state.
• ${{ github.repository }} keeps forks isolated from upstream — each fork gets its own mutex, preserving the template story.

Trade-off

PRs land slightly slower when 2+ are pushed close together (queue wait up to ~45 min worst case). On this repo's PR volume (~5/day max), the queue is rarely hit. Slower-by-design beats 60-min cancellation + re-run + human debug time.

What this PR does NOT do

• Does NOT bump timeout-minutes: 60 — masking the budget is exactly what 9 prior rounds of flake mitigation did.
• Does NOT shard messaging tests N-way — current 1/1 shard works fine when not contended (28 min on chromium-msg when alone).
• Does NOT drop retries — retries weren't the problem.
• Does NOT replace the hand-rolled retry loops in complete-user-workflow.spec.ts or encrypted-messaging.spec.ts — those loops were doing the right thing; they polled while a different CI run was deleting their data. With the mutex in place, they'll succeed on attempt 1.

Test plan

• Pre-push hooks (lint, type-check, build) all green
• Watch the post-merge E2E run on main — should complete without cancellation in ~28-40 min
• Negative test (later): push 2 commits to different branches within 1 min — confirm Actions UI shows "1 queued / 1 running" instead of 2 in parallel

References

• Closes round 10 of the E2E flake pattern called out in STATUS.md:127-129
• Cancelled job log analyzed: https://github.com/TortoiseWolfe/ScriptHammer/actions/runs/25769955636/job/75694213896

🤖 Generated with Claude Code