Bootstrap can remain stuck on "Connecting to gateway…"; add deterministic disconnected fallback

[bmendonca3]

Summary

Studio can remain indefinitely on the bootstrap screen (Connecting to gateway…) instead of transitioning to a disconnected connection form when connect fails.

This appears related to the same user-facing symptom tracked in #82, but this issue is focused on the app-state/UX hardening work needed to make the disconnected fallback deterministic.

Why this matters

When auto-connect fails, users should always be able to quickly edit URL/token and retry. Remaining on a loading screen blocks recovery.

Reproduction (local)

1. Start Studio with empty state (OPENCLAW_STATE_DIR without gateway token).
2. Load /.
3. Observe initial boot transitions to Connecting to gateway….
4. In some runs, UI does not transition to disconnected connection controls.

Expected

• Auto-connect can fail, but UI reliably transitions to a disconnected screen with editable upstream fields and a connect action.
• No indefinite loading state after failed connect.

Actual

• In affected runs, boot UI can stay on Connecting to gateway… for extended time, and disconnected controls do not render.

Proposed scope

• Add explicit bootstrap/connect timeout/fallback policy in connection state handling.
• Ensure failed auto-connect always results in a terminal disconnected UI state.
• Keep retry behavior, but decouple retry from blocking the disconnected controls.
• Add/adjust tests to lock this behavior.

Acceptance criteria

• Failed auto-connect always surfaces disconnected controls within bounded time.
• Manual reconnect still works.
• Existing gateway retry logic remains intact.
• Regression tests cover the fallback transition path.

Related

• Not connecting to gateway #82