[Bug] Builderlab TLS failure blocks first-community creation with no recovery path

**Describe the bug**

During first-run onboarding, selecting Create a community opens Builderlab authentication in the browser. The authentication endpoint fails before any signup UI loads:

login.builderlab.xyz → ERR_SSL_PROTOCOL_ERROR

Buzz remains indefinitely on Waiting for your browser… and provides no error, retry guidance, hosted-service status, or self-hosted alternative.

I reproduced the TLS failure outside the browser as well. A TLS request to login.builderlab.xyz receives a protocol-version alert, while app.builderlab.xyz/api/goose/v1/auth/login responds and redirects into the failing login host.

**To reproduce**

1. Install and launch Buzz as a new user.
3. Complete initial identity onboarding.
5. Select Create a community.
7. Select Sign in to continue.
9. The browser opens a redacted URL beginning with:https://login.builderlab.xyz/authorize?...
11. Observe ERR_SSL_PROTOCOL_ERROR.
13. Return to Buzz and observe that it remains on Waiting for your browser….

Visiting https://builderlab.xyz/ also produced a Cloudflare block page during this attempt.

**Expected behavior**

Builderlab authentication should load and return the user to Buzz.

If the hosted provider is unavailable, Buzz should promptly detect the failed or abandoned flow and offer:

- Retry hosted setup
- Create a self-hosted community
- Connect to an existing relay
- Service-status or support information

**Impact**

This blocks a brand-new user at the first community-creation step. Because Create a community currently exposes only the hosted Builderlab route, users cannot discover Buzz’s supported self-hosted path from the failure screen.

**Environment**

- OS: macOS Golden Gate 27
- Buzz version: 0.4.23 (0.4.23)
- Browser: Chrome Version 150.0.7871.181 (Official Build) (arm64)

**Additional context**

The complete OAuth URL has intentionally been omitted because it contained temporary state, nonce, and PKCE parameters.

The broader hosted-versus-self-hosted onboarding gap is already tracked in #2312.