fix(signalr): force Long-Polling transport so the hub connects through nginx

Server logs showed REST working but ZERO hub activity — the SignalR WebSocket
upgrade isn't getting through the nginx/CDN stack and auto-fallback wasn't
recovering, so StartMatchmaking never reached the server (matchmaking spun
forever). Force the HttpTransportType.LongPolling transport — plain HTTP that
already works (same path as REST); SignalR holds the poll open so it's
effectively real-time for a turn-based game. Revertable once the api block
proxies WS upgrades.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

src/lib/online/signalr-service.ts

@@ -141,10 +141,15 @@ export class SignalrService implements OnlineService {
   private async connect(): Promise<void> {
     if (this.conn || !this.token) return;
     const conn = new signalR.HubConnectionBuilder()
-      // Normal negotiate flow → auto-picks the best transport (WS, else SSE /
-      // long-poll). Requires api.bargevasat.ir to BYPASS the CDN (WCDN 404s the
-      // negotiate POST); with the CDN bypassed this is the most robust path.
-      .withUrl(`${SERVER}/hub/game`, { accessTokenFactory: () => this.token ?? "" })
+      // Force Long-Polling: plain HTTP POST/GET that works through the existing
+      // nginx/CDN (same path REST already uses) without needing WebSocket-upgrade
+      // headers. SignalR holds the poll open, so for a turn-based game it's
+      // effectively real-time. Switch back to default transports once the api
+      // server block proxies WS upgrades.
+      .withUrl(`${SERVER}/hub/game`, {
+        accessTokenFactory: () => this.token ?? "",
+        transport: signalR.HttpTransportType.LongPolling,
+      })
       .withAutomaticReconnect()
       .configureLogging(signalR.LogLevel.Warning)
       .build();