Give GUI startup auth the TUI's non-blocking IAP treatment

[warp-agent-staging]

Description

Fixes the client-side portion of #15342: the Warp GUI blocks startup auth on an IAP token in authenticate_user_after_iap_access, which deadlocks once a cloud sandbox's bootstrap JWT expires (~15-60 min in) — the WIF self-mint that would refresh it needs IAP access itself, so a missing token means no login, indefinitely, with no visible signal why.

• Non-blocking startup auth for the GUI. startup_auth_is_non_blocking now covers LaunchMode::App in addition to Tui: the GUI authenticates optimistically and lets IAP resolve out of band, instead of waiting forever. CommandLine already never reaches this function (it establishes IAP synchronously in its own dispatch path). Test, RemoteServerProxy, and RemoteServerDaemon are left blocking — nothing in this investigation showed they hit the same deadlock, and widening them without evidence risks masking a real auth failure in a headless/test context.
• Loud failure. The non-blocking path now logs a warn when IAP access ultimately times out, so the log an operator/agent is already reading can tell "IAP never came online" apart from "the key was bad" (RefreshFailed is already logged per-attempt by IapManager itself).
• test-warp-ui skill fix. Replaced the stale launch check (provided but IGNORED doesn't exist anywhere in the app source, so it always trivially passed) with a check on the actual startup log line (channel: Dev/channel: Local vs channel: Oss). Also fixed the skill's env var guidance: WARP_API_KEY is frequently a non-user (service-account/team) key in an Oz cloud sandbox that the GUI's startup auth rejects; STAGING_USER_WARP_API_KEY (referenced but never actually set in these sandboxes) is replaced with TUI_AUTH_KEY, which does hold a usable user key.

Descoped: breaking the WIF-mint deadlock itself

The issue also asks for a way for the WIF self-mint to get a fresh subject token that doesn't itself require IAP, and flags a contradiction: the issue's own verified workaround (oz federate issue-token ... from a sandbox with a dead bootstrap JWT) working, versus a comment in iap.rs claiming child oz processes need to transit IAP.

I resolved this empirically in-sandbox rather than guessing:

• https://staging.warp.dev/graphql/v2 answers real GraphQL responses from this sandbox with no IAP header at all — IAP is not actually gating network access here, matching the issue's own observation.
• Running the issue's exact CLI workaround from a cold state (no on-disk token cache, an intentionally-expired bootstrap JWT) reproducibly fails — not with an IAP challenge, but with a local missing authentication credentials error: resolve_wif_identity_token's minter fallback runs as part of establishing IAP access, before the process has authenticated a user, so there's no bearer token to attach yet.
• The issue's own workaround only reproduces when the caller already has a valid on-disk IAP token cache or a working persisted user session — i.e. it isn't actually bypassing IAP for a genuinely cold, expired-bootstrap state; it's reusing state established earlier.
• Even granting a fix for that ordering problem, a persisted-session GUI process retrying the mint mid-session would still be blocked by the issue's own "cause 2" (OZ_RUN_ID stamping X-Warp-Cloud-Agent-ID onto the request, which a user key isn't allowed to use) — a warp-server-side authorization issue in a different repo, out of scope for this PR and not something a client-only change can fix.

Given that, there's no viable in-band, client-only fix for the mint itself. I'm descoping it here; the remaining piece is server-side (warp-server) work, which I'm reporting back separately rather than stretching this PR into another repo.

Linked Issue

• Warp GUI cannot authenticate as a user in cloud sandboxes: OZ_RUN_ID stamps a cloud-agent header the user key may not use, and IAP-gated startup auth has no working mint #15342

Testing

• app/src/lib_tests.rs: extended startup_auth_is_non_blocking_only_for_tui (renamed startup_auth_is_non_blocking_for_gui_and_tui) to assert LaunchMode::App is now non-blocking alongside Tui, while CommandLine/Test/RemoteServerProxy/RemoteServerDaemon stay blocking. This is a direct regression test for the widened scope.

• ./script/format and cargo clippy -p warp --bin warp --tests -- -D warnings pass clean.

• cargo test -p warp --lib (targeted + full run) and cargo test -p warp_server_client --lib (existing iap tests, unmodified) pass; the only pre-existing failures in warp_server_client are unrelated nsc-binary-missing failures in base_client/public_api tests, reproducible on an unmodified checkout in this sandbox.

• cargo build --bin warp succeeds.

• End-to-end: built and launched ./target/debug/warp in this cloud sandbox with a user API key (TUI_AUTH_KEY). Reproduced the onboarding-instead-of-terminal symptom first (with OZ_RUN_ID set, "cause 2" 403s as expected — out of scope here). Then, following the issue's own documented workaround (unset OZ_RUN_ID, supply a freshly-minted IAP token via a shimmed gcloud) to isolate the GUI/IAP behavior from cause 2, the app authenticated in the background and the onboarding wizard led straight into a working terminal — no login screen — where a typed command executed and produced output. See screenshots below.

• I have manually tested my changes locally (cargo build --bin warp + running the resulting binary; ./script/run requires interactive channel-config setup not available in this environment, see PR for details)

Screenshots / Videos

The last screenshot below is the target end state: a working, authenticated terminal reached without a login screen, in this cloud sandbox. The earlier ones show the onboarding screen (both the "cause 2" 403 case and, per the issue's own noted caveat, the first-run onboarding wizard that a fresh profile shows regardless of auth state) before the workaround.

Computer-use screenshots (10)

Desktop state after attempting to launch Warp: no application window opened; only the desktop wallpaper and empty Tint2 taskbar are visible, since the warp process panicked and exited immediately before creating any UI.

Warp application window showing the onboarding "Welcome to Warp" screen with a "Get started" button and "Already have an account? Log in" link, instead of an authenticated terminal prompt.

Warp onboarding screen after clicking into the window and typing "echo hello" — no terminal prompt or text input appeared; the screen remains unchanged, showing no evidence of an interactive shell.

The Warp application window showing the onboarding screen with "Welcome to Warp" heading, a "Get started" button, and a "Log in" link — no terminal prompt is present.

Screen 1: Welcome to Warp screen with "Get started" button and "Already have an account? Log in" link.

Screen 2: "Customize your Warp" onboarding screen showing Tab styling, Tools panel, and Code review options, with "Back" and "Next" buttons.

Screen 3: "Choose a theme" onboarding screen with Phenomenon, Dark (selected), Light, Adeberry theme options and "Back"/"Next" buttons.

Screen 4: Terminal session view with "Welcome to terminal mode" tooltip overlay explaining terminal mode, with a "Next" button to continue the tour.

Screen 5: "You're in agent mode" tooltip explaining agent mode conversation, with "Back to terminal" and "Finish" buttons.

Final screen: Terminal session showing the executed command "echo hello-from-verification" with its output "hello-from-verification" displayed, confirming a working authenticated terminal was reached without requiring login.

Agent Mode

• Warp Agent Mode - This PR was created via Warp's AI Agent Mode

[warp-agent-staging]

This PR was generated with Warp.

Comment @warp-factory on this PR to send it follow-up work.