test(domain): guard the ranked arena list against Godot registry drift

Task 8.20. `arena_registry.gd` is the documented single source of truth
for arenas, but `domain/ranked.go` keeps a hand-maintained mirror of its
floor-goal entries and nothing checked the two against each other --
ranked_test.go asserts the same three paths the production code
hardcodes, so both could drift together silently.

Drift is not hypothetical in either direction. The registry's own comment
anticipates flipping an elevated variant to random:true once a checkpoint
trained on that geometry is promoted, which ranked would then keep
excluding indefinitely. A rename or removal is worse: the allocator would
hand out a scene path that no longer exists, and the ranked server fails
to load its arena at match start -- after allocation, so it burns a real
match and a real server.

Keeping the two copies is deliberate rather than a wart: ranked arena
selection is server-authoritative and happens before any Godot process
exists. So this guards the relationship instead of removing it, the same
way the golden join-authorisation token guards the signing format. It
parses the registry and fails if the sets disagree either way, if
rotation order diverges from declaration order, or if a ranked path has
no scene behind it. The parser asserts it found both eligible and
ineligible entries, so a format change cannot make everything pass
vacuously. Verified against four drift scenarios.

The allocation-wiring half of 8.20 turned out to be already complete end
to end, with coverage at each hop; recorded in the task row rather than
rebuilt.

Add a Server Unit Tests workflow, because none of this would otherwise
run: the only Go tests CI executed were multiplayer-load's two load
tests, so ~24k lines of control plane gated nothing. Docker-free so it
can gate every push, and it vets the integration-tagged files too, since
those are excluded from the default build and could otherwise rot
uncompiled.

CLAUDE.md's CI section claimed two workflows and no unit-test job; there
were seven and now eight.

.github/workflows/server-unit-tests.yml

@@ -0,0 +1,47 @@
+# The Go control plane is ~24k lines, and until this workflow existed the only
+# Go tests CI ever ran were the two load tests in multiplayer-load.yml. Nothing
+# else — domain policy, the wire/store boundaries, the allocator, the Steam
+# adapter — gated a change. The Godot unit suite is covered (verify-phase6 runs
+# test_runner.tscn as its first step); this closes the equivalent gap on the
+# Go side.
+#
+# Deliberately Docker-free and cluster-free so it stays fast enough to gate
+# every push. Tests that need a real PostgreSQL or Redis are behind the
+# `integration` build tag and stay with their own scripts; `go vet` is still
+# run over that tag so those files cannot rot uncompiled.
+name: Server Unit Tests
+
+on:
+  push:
+  pull_request:
+
+permissions:
+  contents: read
+
+jobs:
+  go-tests:
+    runs-on: ubuntu-latest
+    defaults:
+      run:
+        working-directory: server
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-go@v5
+        with:
+          go-version-file: server/go.mod
+          cache-dependency-path: server/go.sum
+      - name: Build
+        run: go build ./...
+      - name: Vet
+        run: go vet ./...
+      # Integration-tagged files are excluded from the default build, so
+      # without this a signature change could leave them broken until someone
+      # ran the integration scripts by hand.
+      - name: Vet integration-tagged tests
+        run: go vet -tags integration ./...
+      - name: Test
+        run: go test ./...
+      # The control plane is concurrent by design: outbox dispatchers, the
+      # event hub, the matcher worker and the allocator all run in parallel.
+      - name: Test with race detector
+        run: go test -race ./...