fix(server): relay test-run completion broadcast via Oban so dashboards refresh

Purpose

A finished test run could stay stuck on the “processing” spinner in the web UI even though ClickHouse already showed status=success — the run looked perpetually unprocessed until the user manually refreshed the page.

Root cause

The test-run detail LiveView (TestRunLive) shows the spinner purely off @run.status == "processing" and only clears it when it receives a {:test_created} PubSub message — there is no polling. That broadcast is emitted from inside Tests.create_test/1, which for most runs executes on the xcresult-processor. The processor runs as an isolated, non-clustered BEAM node (no TUIST_CLUSTER_DNS_SERVICE / RELEASE_DISTRIBUTION, on the Tart NAT network, not in the tuist-tuist-server-headless endpoints), and Tuist.PubSub uses the default PG2 adapter, which only delivers across Erlang-clustered nodes. So the completion broadcast was emitted on a node that can’t reach the web tier and the LiveView never updated.

What changed

1. Relay the broadcast through Oban (Tuist.Tests.Workers.BroadcastTestCreatedWorker). Tests.create_test/1 now enqueues the broadcast on the :default queue instead of broadcasting in-process. The :default queue is consumed only by web pods (the build- and xcresult-processor fleets each run a single dedicated queue), so the job always runs on a clustered web node and the PG2 broadcast reaches every subscribed LiveView. The payload (%Test{}) and topic ("<account>/<project>") are unchanged, so all subscribers behave exactly as before — only the node that emits the broadcast moves.

2. Poll fallback in TestRunLive. While a run is processing, the LiveView re-checks every 5s and self-heals even if the broadcast is ever lost (cluster/Redis blip, crash, a client that missed the message). It stops polling once the run reaches a terminal status.

Why this approach

The processor is NAT-isolated by design and reaches Postgres/Oban over Tailscale; it shares the Oban/Postgres backend with the web tier but cannot reach the in-cluster tuist-tuist-redis ClusterIP. Relaying through Oban reuses infrastructure the processor already depends on — no new network exposure, no Tailscale ACL change, and no need to switch the global PubSub transport to Redis (which would otherwise be required to bridge the node boundary). The poll fallback is defence-in-depth and also helps clients whose WebSocket reconnects.

Impact

• Test-run dashboards update on their own when a run finishes processing on the external processor (the common case), instead of appearing stuck until a manual refresh.
• No behavioural change for any PubSub subscriber — the broadcast payload/topic are identical.
• One extra lightweight Oban job (:default queue) per test-run creation.

How to test locally

cd server
mix test test/tuist/tests/workers/broadcast_test_created_worker_test.exs \
         test/tuist_web/live/test_run_live_test.exs

• The worker test asserts the broadcast lands on the project topic and is a no-op for a missing run.
• The TestRunLive test asserts a processing run clears its spinner via the poll even when no broadcast is delivered.

Notes for reviewers

• An unrelated plug_cowboy 2.8.1 → 2.9.0 bump was present in server/mix.lock in the worktree and is intentionally not included in this PR.
• Follow-up: build runs likely share the same cross-node isolation (the build processor TUIST_MODE=processor is also non-clustered); if there is an analogous completion broadcast it would want the same relay.