Fall back to device code auth when the localhost browser callback can't complete

Problem

rsconnect login <server> uses an OAuth authorization code flow with a localhost redirect URI. That flow can't complete when the CLI runs on a remote/hosted environment (e.g. Posit Workbench, or any container/cloud session) because the browser that opens is not on the same host as the CLI listener.

Today the user is left with a hung or failed login and no indication of what to do next. The workaround exists — rsconnect login <server> --use-device-code (added in 1.30.0) — but it has to be discovered and typed manually. In practice users, and agentic tools driving the CLI, repeatedly fail the browser flow before finding it.

Requested behavior

Automatically fall back to the device code flow when the authorization code flow can't succeed. Two complementary options:

1. Detect-and-prefer: when running in an environment where a localhost callback is unlikely to reach the user's browser, default to device code.
2. Fail-and-retry: if the browser flow times out or the callback never arrives, print a clear message and retry with device code instead of erroring out.

This mirrors what other CLIs do — Claude Code, for example, falls back to device code automatically when its localhost redirect fails, which is why it works in Workbench.

Notes / prior art

• Posit Publisher works around this on Workbench by using a public-facing callback URL registered in our Connect instances, but that required Workbench-specific code in Publisher to detect the environment. Generalizing that mechanism is a possible longer-term path for first-party tools; third-party tools would still need device code.
• Device code requires a recent enough Connect, so the fallback should degrade gracefully

Inizia dal comando di accesso rsconnect e segui il percorso esistente --use-device-code insieme al flusso di callback del browser su localhost. Determina come viene segnalato un errore o un timeout del callback, quindi definisci il comportamento di fallback e la gestione corretta per le versioni di Connect che non supportano device code. Il lavoro sarà completato quando le sessioni remote o ospitate non lasceranno più gli utenti con un accesso bloccato e forniranno un percorso chiaro per il recupero.