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

Beginne beim rsconnect-Login-Befehl und verfolge den bestehenden --use-device-code-Pfad parallel zum localhost-Browser-Callback-Flow. Ermittle, wie ein Callback-Fehler oder -Timeout angezeigt wird, und definiere anschließend das Fallback-Verhalten sowie die ordnungsgemäße Behandlung für Connect-Versionen, die device code nicht unterstützen. Als erledigt gilt die Aufgabe, wenn Remote- oder gehostete Sitzungen Benutzer nicht mehr mit einem hängenden Login zurücklassen und einen klaren Weg zur Wiederherstellung bieten.