`CCloudOAuth` provider: login + on-request refresh + two auth views

[jlrobins]

• Goal: the orchestrator that owns one login and one shared TokenSet, vending two thin
  httpx.Auth views over it and keeping tokens current by synchronous on-request refresh — no
  background thread. This is the correctness floor and the functional proof of concept; the
  latency-smoothing daemon is deferred to child 7.
• Scope (in):
  • login(org_resource_id) — PKCE → callback server → webbrowser.open → hops 1–3 → populate the
    TokenSet (both tokens) → stash the resolved organization.resource_id.
  • data_plane_auth / control_plane_auth adapters — each reads its token off the current
    immutable snapshot under _token_lock (microseconds), stamps Authorization: Bearer <token>,
    and when the token is stale or a 401 comes back refreshes synchronously through the
    _refresh_lock single-flight gate before yielding. This on-request path is the entire refresh
    story here, and it is what makes correctness independent of any background thread: it re-mints
    fresh CP/DP tokens from the long-lived (4h-idle / 8h-absolute) refresh token whenever the
    short-lived (~5-min) tokens have lapsed, however long the connection sat idle.
  • _refresh() — runs the chain under single-flight, double-checks for a newer snapshot before
    spending the single-use refresh token, and persists the rotated refresh token before the
    CP/DP exchanges.
  • Baseline 8h-wall behaviour: on absolute-expiry refusal, set the failure flag and let the
    next auth_flow raise a catchable ReauthenticationRequired.
• Out of scope: in-place re-auth recovery + the reauth= policy knob (child 6); the background
  refresh daemon (child 7) — an optimization, not correctness; proactive re-login ahead of the wall
  (child 8); the process-wide holder (child 4); connect() wiring (child 5).
• Depends on: OAuth primitives: pkce + token_chain + token_set #151, Local callback HTTP server #152
• Reference: #399 OAuthCredentialsProvider (single-flight + double-check) and
  OAuthTokenAuthenticator (401 → one retry) — noting our refresh token is single-use/rotating,
  so our single-flight is load-bearing for correctness, not just efficiency.
• Prior art: ide-sidecar — Bearer stamping CCloudDataPlaneAuthenticationProcessor.process()
  and the context's getDataPlaneAuthenticationHeaders() / getControlPlaneAuthenticationHeaders()
  (that header pair is our two-view analogue); the refresh runs under a per-context
  ReentrantReadWriteLock write lock (its single-flight). mcp-confluent — oauth/auth-context.ts
AuthContext: refresh() single-flight via the inflightRefresh promise and doRefresh()
  persisting the rotated refresh token before the CP/DP legs (our exact ordering); the two-views
  mapping lives in oauth-client-manager.ts (cloud/tableflow arms → CP token, flink arm → DP token).
  (Both also run a background refresh loop — that's the child-7 daemon, not this child.)