[Rust][Python] Add first-class federated-token auth (external IdP / Entra ID)

[anilmenon14]

Motivation

Enterprise customers who cannot use Databricks-managed OAuth secrets currently
cannot use Zerobus. This PR adds an opt-in authentication mode that federates an
external identity provider (for example Entra ID) token into a Zerobus-scoped
Databricks token, client-side, so those customers can stream without a
Databricks secret. The platform token exchange already works on gRPC via the
undocumented HeadersProvider hook; this makes it first-class instead of a
workaround. The Zerobus service is unchanged.

What this changes

• Rust core: new FederatedTokenProvider (implements the existing
  HeadersProvider trait, including invalidate()) and an IdpTokenSupplier
  callback type. The client-credentials and token-exchange grants now share one
  request-shaping path in default_token_factory.rs, keeping them at parity.
  Opt-in StreamBuilder::federated(...) and federated_with_client_id(...).
• Python binding: auth=FederatedToken(idp_token_supplier=..., databricks_client_id=...)
  on create_stream (sync and async), with the Python callback bridged across
  FFI (sync and async callbacks both supported). The HeadersProvider.invalidate()
  hook is now forwarded through the Python bridge.
• No existing signatures change behavior.

Resolves #740

The two supported modes

• Account-level federation: (databricks_client_id omitted): no Databricks
  service principal. The exchanged token's subject resolves to an identity
  synced into Databricks via Automatic Identity Management (SCIM). The exchange
  request omits client_id.
• Workload identity federation: (databricks_client_id set): a Databricks
  service principal with a client_id and no secret, with a federation policy
  attached. The exchange request names the service principal via client_id.

Backward compatibility

The client_id/client_secret (OAuth) and headers_provider paths are
unchanged. The new behavior is reached only when the caller passes the new,
opt-in auth=FederatedToken(...) argument (or the federated* builder methods
in Rust).

Testing evidence

• Rust: unit tests for request-shaping parity with/without client_id, plus
  end-to-end provider tests against a mock token endpoint (caching, invalidate()
  re-mint, mode independence, supplier-error propagation). All lib tests pass;
  clippy and rustfmt clean.
• Python: dispatch/routing and argument-validation tests. black, isort,
  pycodestyle clean.
• Live (both modes, against a real workspace, streaming to a UC table): a
  successful stream on gRPC for account-level and workload identity federation;
  caching confirmed (the IdP callback fires once across multiple streams from one
  SDK); a >1 hour soak showing the exchanged token auto-refreshes near the
  ~55-minute mark (token lifetime ~60 min minus the 300s cache buffer) with no
  interruption; and an async callback validated via the async SDK.

REST insert path (resolved, not a limitation)

The same federated exchange token works on the REST insert endpoint
(/zerobus/v1/tables/<table>/insert), verified live with an HTTP 200 insert.

Known limitations / follow-ups

• Other language bindings (TypeScript, Java, Go, C++) to follow.
• A server-side / control-plane exchange remains a reasonable later phase (it
  would cover non-SDK and REST callers uniformly); this PR is the client-side
  first step.
• Suggested maintainer test follow-up: the sync callback is unit-tested and
  live-verified; the async callback bridge and the Python FFI error mapping are
  verified live but not yet covered by automated unit tests, because both need a
  live token+gRPC endpoint or a fuller mock harness. Adding CI coverage for these
  two using the repo's test fixtures would be worthwhile.

Housekeeping

• DCO sign-off on all commits; GPG-signed.
• NEXT_CHANGELOG.md updated (Rust core and Python).
• README and an examples/ sample added for the new API.