feat(spark): add OIDC federation token provider to the UC connector

[parisni]

Why

The 0.2.x Spark connector could only authenticate with a static token or an OAuth
client-credentials secret. Both are password-equivalents that must be stored and rotated. A
Kubernetes workload can instead prove its identity with the service account token the kubelet
already projects for it, so nothing secret is stored on either side.

What

OIDC federation provider

• New FileOidcUCTokenProvider: RFC 8693 token exchange over the JDK HTTP client, consistent with
  the 0.2.x backport constraints (no RetryingApiClient/Clock available here). Token cached and
  renewed 30s before expiry, thread-safe via double-checked locking, like OAuthUCTokenProvider.
• The subject token is re-read on every renewal rather than cached at initialization: the kubelet
  rotates the projected file and a Spark session outlives a single token.
• No Authorization header on the exchange — the subject token is the proof, there is no secret.
• New options oidc.uri, oidc.clientId, oidc.tokenFilePath.

Alignment with the 0.3.x option formalism

• UCTokenProvider gains initialize(Map) and create dispatches on a type key (static,
  oauth, oidc, or a fully qualified custom provider class name), mirroring 0.3.x including the
  custom-class escape hatch.
• AuthConfigs holds the key constants, named exactly as upstream, so a future rebase is a package
  move rather than a rename.
• AuthConfigUtils is backported to normalize catalog options, strip the auth. prefix and reject a
  key configured twice. Extended beyond upstream to infer a type from the un-prefixed keys this
  connector already shipped, so existing configurations keep working untouched.
• UCSingleCatalog delegates to AuthConfigUtils and keys off the presence of type.

Renewable S3 vended credentials

S3 was the one cloud whose vended credentials landed in the plan as literal
fs.s3a.access.key/secret.key/session.token. They last about an hour, so a stage outliving them
failed on S3 rather than on anything resembling an auth problem. Azure and GCS already went through a
token provider.

S3VendedCredentialsProvider is an S3A credentials provider that re-requests credentials from UC
before they expire, keyed by table scope. It is installed on the executors too, which is why the UC
coordinates and the auth configuration travel in the Hadoop configuration: the driver's provider
instance does not cross the plan, so each side re-authenticates on its own. With oidc, that means
the projected token has to be mounted on the executors as well.

The cache is static, because generateCredentialProps sets fs.s3a.impl.disable.cache=true: Spark
rebuilds the FileSystem, and the provider with it, on every resolution, so an instance cache would
never be reused.

This is inactive while skipCredentialVending=true, which is the current setting. It is here so
that turning vending on later is a configuration change rather than a code change.

What is deliberately not here

Upstream 0.3.x ships a connectors/hadoop module for this, whose GenericCredentialProvider is
generic over four clouds and five credential scopes, and which rebuilds providers through
TokenProvider.configs(). Not backported:

• it needs client internals absent from 0.2.x (client.internal.Clock, ApiClientUtils,
  RetryingApiClient, client.delta.api.*, client.auth.TokenProvider);
• moving the connector to 0.3.x instead is not an option on our side: it builds for Spark 4.0+ and
  Scala 2.13 only, while this distribution is Spark 3.5.8 / Scala 2.12.

So the provider here collapses that hierarchy into one table-scoped, S3-only class. There is no
configs() accessor either: it is only needed to rebuild a provider generically, which this
single-purpose provider does directly from the Hadoop configuration.

Compatibility

Existing modes are untouched and keep precedence: an explicit type wins, otherwise token infers
static and the oauth.* keys infer oauth. A blank value counts as unset, so an unauthenticated
metastore stays unauthenticated. No current catalog configuration has to change.

Tests

60 tests passing: 31 unit + the 29 TableReadWriteTest integration tests.

• FileOidcUCTokenProviderTest (6): request shape, caching, re-read + re-exchange after expiry,
  non-200 propagation, missing and empty token file.
• UCTokenProviderTest (8): dispatch per type, custom class instantiation and its failure, missing
  type, incomplete oauth.* / oidc.*.
• AuthConfigUtilsTest (12): prefix stripping, type inference for the three legacy shapes, explicit
  type winning, double-configuration rejection, blank values, case insensitivity.
• S3VendedCredentialsProviderTest (5): bootstrap credentials served without calling UC, absent
  expiry treated as non-expiring, renewal triggered inside the lead time, cache shared across
  provider instances of one scope, scopes isolated from each other.

build/sbt "spark/testOnly io.unitycatalog.spark.*"             # 60 tests, 0 failures
build/sbt "spark/checkstyle" "spark/Test/checkstyle"

Note: this project's build.sbt asserts JDK 17+.

Notes for the reviewer

• Review by commit rather than squashed: commit 3 walks back a configs() accessor that had no
  caller, and commit 4 fixes a regression commit 2 introduced. The history carries the reasoning.
• Neither the OIDC exchange nor the credential renewal has been driven against a live UC endpoint;
  both are covered with mocks. The renewal path in particular is exercised only up to the point where
  it would call UC.
• build.sbt gains software.amazon.awssdk:auth as Provided, alongside the existing GCS and ABFS
  SPI dependencies. hadoop-aws supplies it at runtime.
• I could not identify a job that needs oidc through UCSingleCatalog today: the LBCTRANSDA-567
  consumers all go through the Databricks SDK, not this connector.