Process-wide holder: one OAuth identity per process

[jlrobins]

• Goal: guarantee exactly one browser login per process even under dbt multi-threaded mode
  (one Connection per worker) — the browser bounces once, not once per worker.
• Scope (in): a module-level singleton owning the provider + TokenSet; login single-flight via
  a one-shot ready future (first connect() logs in, the rest block on its completion-or-failure and
  share it); the one-identity guard (a later connect() naming a different organization_id raises
  InterfaceError; an omitted one inherits the established org); a shutdown_all() escape hatch for
  test isolation and tidy teardown.
• Deferred to child 7: the refcount + park-don't-evict + linger lifecycle. Without a
  background thread there is nothing to park at refcount 0, so the baseline holder simply keeps the
  shared provider alive until shutdown_all() or interpreter exit — the holder-side half of the
  daemon simplification.
• Out of scope: connect() invoking it (child 5) — this child is built and concurrency-tested
  standalone first; the daemon and its refcount lifecycle (child 7).
• Depends on: CCloudOAuth provider: login + on-request refresh + two auth views #153.
• Prior art: mcp-confluent is the direct analogue — oauth/oauth-holder.ts OAuthHolder owns
  the single AuthContext, with ensureLoggedIn() single-flight via a shared inFlightLogin
  promise; the "one OAuth identity" rule is enforced at config load (rejects multiple type: oauth
  connections — CONFIGURATION.md). ide-sidecar is the counter-example: no process-wide
  identity — auth is per-connection (CCloudConnectionState each owns a CCloudOAuthContext), the
  only app-wide singleton being the connection registry ConnectionStateManager. That per-connection
  duplication is exactly what our holder exists to avoid.
• Sized right: singleton + login single-flight + concurrency tests; no daemon, no refcount, no
  connect() surface yet.