ci: give the e2e workflow its own concurrency group (#263)

Root cause of both v2.9.0 release failures: in a workflow_call context,
`github.workflow` resolves to the CALLER's workflow name, so e2e.yml's
concurrency group evaluated to release.yml's exact group
(`Release-refs/tags/v2.9.0`) with cancel-in-progress: false - the called
run deadlocked behind its own parent and failed at startup with zero
jobs. Standalone dispatch worked (group E2E-...), which is why this
never surfaced before the first gated release. A literal `e2e-` prefix
keeps per-ref dedup for manual dispatches while never colliding with a
caller. The v2.9.0 tag will be re-pointed after merge.

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

https://claude.ai/code/session_015jEKvjBzVjaWLq6o5zg2PV

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

Author: pmaxhogan

.github/workflows/e2e.yml

@@ -23,8 +23,14 @@ on:
 permissions:
   contents: read
 
+# The group MUST NOT use github.workflow: in a workflow_call context that
+# expression resolves to the CALLER's workflow name, which made this group
+# identical to release.yml's own concurrency group - so the called run
+# deadlocked behind its parent and failed at startup with zero jobs (the
+# v2.9.0 release, twice). A literal prefix keeps dispatch dedup per ref
+# while never colliding with a caller.
 concurrency:
-  group: ${{ github.workflow }}-${{ github.ref }}
+  group: e2e-${{ github.ref }}
   cancel-in-progress: false
 
 jobs: