Hosted community subdomain: mobile pairing stuck on "Connecting..." / code expires instantly (related to #2662)

## Summary

On a **hosted** community subdomain (`*.communities.buzz.xyz`, not self-hosted), mobile device pairing fails consistently: the "Add Community" screen on iOS sits on "Connecting..." indefinitely, and the Activity tab shows "Failed to load activity" with a Retry button that does not resolve it.

This looks related to #2662, but that issue was diagnosed against a **self-hosted** relay (missing pairing endpoint, WebSocket 404 on a custom reverse proxy). This report is the same symptom on a **Block-hosted** `communities.buzz.xyz` instance, where the reporter has no infrastructure to misconfigure — everything is on Block's own servers.

## Environment

- Community: hosted subdomain on `communities.buzz.xyz` (dev workspace)
- Desktop app: Buzz desktop v0.5.3, Windows 10 Pro
- Mobile: Buzz iOS app, iPhone
- Desktop and mobile are the same account/workspace; desktop is fully functional

## Steps to reproduce

1. On desktop, an identity migration to this device had previously completed (`identity.migrated` flag present in app data).
2. On iOS, open Buzz → the hosted community loads to "Connecting..." and never resolves.
3. Activity tab → "Failed to load activity" → Retry does not help.
4. Attempted device pairing flow (Settings → add device / "Add Community" → Scan QR / paste pairing code): the desktop-side code/QR appears to invalidate before the mobile side can complete the exchange, even when copying the pairing text directly (via OS clipboard) instead of live-scanning — ruling out scan speed as the cause.

## What we checked before filing

- Confirmed the hosted endpoint responds (not a DNS/outage issue): `curl -I https://.communities.buzz.xyz` → `200`/`403` depending on path, served via Cloudflare — the service is up.
- Confirmed there is no self-hosted relay or reverse-proxy config anywhere in our infra for this community — it is fully Block-hosted, so the "run the standalone pairing-relay process" workaround from #2662 does not apply here.
- Ruled out client-side timing as the cause: even copying the pairing code/link via clipboard (no live QR scan) and pasting immediately still fails, suggesting the code is invalidated server-side (e.g., on relay reconnect / focus loss) faster than a human round-trip between two screens can complete on a single device.

## Ask

Could someone confirm whether the hosted `communities.buzz.xyz` pairing relay has the same missing-endpoint issue as the self-hosted case in #2662, or whether there's a separate TTL/invalidation bug specific to hosted workspaces? Happy to provide desktop logs / HAR capture if useful.

Start by reproducing the Settings → Add device/Add Community pairing flow on the hosted communities.buzz.xyz workspace and compare its behavior with the self-hosted case in #2662. Inspect the hosted pairing relay behavior around the instantly expiring code and the mobile “Connecting...” state; done means determining whether this is a missing endpoint or hosted-workspace TTL/invalidation bug and documenting the fix or next diagnostic evidence.

Written by the indexing model from the issue text.