Serialize device auth to reuse concurrent logins

[maennchen]

Problem

device_auth was the only auth-resolution path in hex_cli_auth not wrapped in global:trans. Concurrent callers that all needed to authenticate (e.g. parallel commands run with no credentials) each kicked off their own device auth flow — prompting the user and persisting a token multiple times instead of sharing a single login.

Fix

• Wrap maybe_authenticate_and_retry in a single global lock. The device auth token is always persisted to the global OAuth scope, so the lock is intentionally not keyed by repo.
• Inside the lock, re-resolve auth first and reuse a token that differs from the one the caller arrived with — a caller that was waiting on the lock picks up the login a prior winner just persisted instead of prompting again.
• The "differs from current" check covers both entry reasons:
  • no_credentials — no key in config, so any resolved token differs → reuse.
  • token_refresh_failed — the rejected key is in config, so the winner re-runs device auth while a later waiter reuses the freshly persisted token.
  • It also avoids an infinite retry loop when the server keeps rejecting a token that still looks valid by expiry.

Test

Adds a regression test that drives concurrent callers through a barrier and blocks the winner inside should_authenticate, asserting exactly one caller is prompted and the persisted login is reused by the rest. It fails against the unfixed code (multiple concurrent prompts) and passes with the fix. Full suite: 33/33.

[ericmj]

@maennchen Let me know if this is ready to merge

[maennchen]

@ericmj Ready. But I'll open more for other stuff surfacing over in hex later.