[Bug]: Meta Muse device OAuth UI still presents callback-paste semantics and can show stale login hints #5881

Area

Authentication / provider login UI

Summary

Meta Muse uses a device-code OAuth flow. After the user opens the Meta verification URL and approves the human-readable code, OpenCodex should keep polling and settle the login automatically.

The backend device flow already does that, but the shared add-provider OAuth UI still mixes device-code semantics with the manual redirect/callback paste fallback. In addition, later onAuth hint transitions from a long-running device flow are not reliably projected through the login-status surface, so the UI can remain on an older hint while the provider flow has moved on.

This makes a successful Meta approval look like OpenCodex is still waiting for a callback URL even though no callback paste is required for the device grant.

Verified against current main e70b3d86fb1201d7951dfeb25e09b7871c433047 (2.66.0): gui/src/components/login-url-block.tsx is device-code capable but the paste fallback is still rendered independently of that mode.

Reproduction

1. Add/login to meta-muse using OAuth from the dashboard.
2. Open the Meta device verification URL and enter the displayed Muse code.
3. Approve the code on Meta.
4. Return to OpenCodex.

The provider backend continues polling, but the UI can still present the redirect/callback paste affordance or stale instructions, implying that the operator must paste a callback.

Expected behavior

For a device-code login:

• show the human-readable device code, verification URL, and provider instructions;
• do not show the redirect/callback paste field while a deviceCode is active;
• expose the current live login hint through the status endpoint so later onAuth transitions replace stale URL/code/instructions;
• after approval, polling should settle the login automatically and persist the account with no manual callback input;
• cancellation should clear the transient hint.

Manual callback/code paste remains useful for authorization-code providers and should stay available there.

Suggested implementation shape

• Keep the latest auth hint in the login-flow state, not only the first hint returned by startLoginFlow.
• Include the current url, deviceCode, and instructions in getLoginStatus while the flow is active.
• Update the add-provider OAuth hook from the polled status hint.
• Gate the callback/paste component on the absence of deviceCode.

Regression coverage

A deterministic public-surface test can pin:

1. first onAuth publishes a device URL + device code;
2. a later onAuth replaces the live hint without restarting the flow;
3. no manual callback submission occurs;
4. the flow settles done=true / loggedIn=true;
5. the device-code UI hides callback paste while the device code is active.

A real Meta Muse smoke additionally confirms:
approval -> polling -> persisted account -> inference.

Checks

• I searched existing Meta Muse/device OAuth issues; I did not find an equivalent report.
• No device code, OAuth token, email, account ID, or private endpoint is included.
• The report separates backend polling (already present) from the UI/state projection bug.