Epic: Interactive human-login OAuth for `confluent_sql`

This epic gives the driver a full interactive browser login: a three-hop Auth0 PKCE chain that mints *Confluent's own* control-plane and data-plane tokens, refreshed by a background daemon and shared process-wide. Unlike the sibling BYOIDC epic — where the caller supplies an external token good only for the Flink data plane — a Confluent-minted control-plane token reaches the **whole** surface: Flink **plus** Tableflow, Connect, and CMK. One human login collapses up to three API-key pairs into one credential.

The neighboring Java client ([confluent-flink-plugin-private#399](https://github.com/confluentinc/confluent-flink-plugin-private/pull/399), squash `64b3b17`, FTAB-97) shipped machine-to-machine OAuth — a static token or a refreshing client-credentials provider — but **never** an interactive browser login, the `/api/sessions` → `/api/access_tokens` control-plane chain, or a process-wide multi-Connection holder. Those are this epic's distinguishing work: the reach the plugin's Flink-data-plane-only scope never had to touch. (The plugin's BYOIDC modes are covered by the sibling **#148** instead.)

This epic reuses the polymorphic `_flink_auth` slot and the `connect()` auth-mode selection point that #100 / PR #146 built (the first step of the BYOIDC epic). It does **not** depend on that epic's child 2; the two epics diverge past the shared seam and can proceed in parallel.

Alas, dbapi is synchronous/blocking python, so we have to resort to using threads / a short lived webserver thread to receive the success/failure oauth callback. [A new markdown document](https://github.com/confluentinc/confluent-sql/blob/oa/153-ccloudoauthprovider/OAUTH_CONCURRENCY_MODEL.md) in there repo (for reviewer / claude reference) describes how concurrency will be handled in the face of multiple `Connection`s in multiple threads (a many-threaded dbt session kicking off) each racing to start up the oauth process.

Remember while implementing:
* We're using branch `oauth-epic-integration` as integration branch off of main for all of the child issues to base off of. When epic functionality is complete, we'll then merge into main, but we'll PR each reasonable piece at a time.
* Read and review all child issues to gain context on where the current issue sits in the grand scheme of things to be sure to not do more than is needed in any individual child.