ci/ui-test: queue runs in one bucket instead of cancelling

`cancel-in-progress: true` killed run #73 even though it was the
only ui-test in its concurrency group — Gitea appears to cancel the
in-progress job on its own under that setting in some edge cases.

Switch to a singleton group with `cancel-in-progress: false`. The
new behaviour is simple queueing: only one ui-test workflow runs at
a time across the repository, the rest wait. Vite-on-:5173 cannot
collide because there is never a second ui-test alive. The wall-time
hit is bounded — ui-test is ~2 minutes — and bursts are rare enough
that queueing is cheap.

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

.gitea/workflows/ui-test.yaml

@@ -16,14 +16,17 @@ on:
       - '.gitea/workflows/ui-test.yaml'
       - '!**/*.md'
 
-# Playwright launches its own `pnpm dev` on :5173. In host-mode the
-# runner shares the host's port namespace, so two parallel ui-test
-# jobs (e.g. a push event racing with a pull_request event for the
-# same commit) collide on EADDRINUSE. Group by the head commit so
-# push and pull_request events for the same sha share one bucket.
+# Playwright launches its own `pnpm dev` on :5173, and in host-mode
+# the runner shares the host's port namespace with every other job,
+# so two parallel ui-test runs collide on EADDRINUSE. Serialise via a
+# singleton concurrency group with queueing — new runs wait their
+# turn instead of cancelling the in-progress one. cancel-in-progress
+# is explicitly false because Gitea has shown spurious self-cancel
+# behaviour under cancel-in-progress: true even when no other run
+# shares the group.
 concurrency:
-  group: ui-test-${{ gitea.event.pull_request.head.sha || gitea.sha }}
-  cancel-in-progress: true
+  group: ui-test-singleton
+  cancel-in-progress: false
 
 jobs:
   test: