tui: route device-code auth through app server

[etraut-openai]

Addresses #7646
Also enables device code auth for remote TUI sessions

Problem: TUI onboarding handled device-code login directly rather than using the recently-added app server support for device auth. Also, auth screens kept animating while users needed to copy login details.

Solution: Route device-code onboarding through app-server login APIs and make the auth screens static while those copy-oriented flows are visible.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 3e1e22117d

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[daniel-oai]

Tested this locally and it worked great. I also had Codex do a careful review pass, and it found one P2 issue that might be worth adding a small fix for before merging.

Quoting the Codex review note separately:

I think this should also cancel the app-server login if the start response comes back after the TUI attempt is no longer active.

Right now, if the user presses Esc while account/login/start is still in flight, the TUI moves back to PickMode. When the app server later returns ChatgptDeviceCode { login_id, ... }, set_device_code_state_for_active_attempt(...) returns false, but we drop the login_id without sending account/login/cancel. At that point the app server has already started polling and the stale attempt can keep running until timeout or until another login replaces it.

Suggested shape:

let updated = set_device_code_state_for_active_attempt(
    &sign_in_state,
    &request_frame,
    &request_id,
    ContinueWithDeviceCodeState::ready(
        request_id.clone(),
        login_id.clone(),
        verification_url,
        user_code,
    ),
);
if updated {
    *error.write().unwrap() = None;
} else {
    cancel_login_attempt(&request_handle, login_id).await;
}

That helper could mirror the existing cancel_active_attempt request path by sending ClientRequest::CancelLoginAccount { params: CancelLoginAccountParams { login_id }, ... }. This keeps ownership aligned with the new app-server device-code flow: once the app server creates a login attempt, the TUI should either adopt it or explicitly cancel it.

[etraut-openai]

Fixed in a625093324.

Good catch: if the TUI backed out while account/login/start was still in flight, we could drop the later login_id on the floor and leave the app server polling a stale device-code login. I pulled the cancel request into a shared TUI helper and now explicitly cancel that stale login when the response arrives after the attempt is no longer active.