CRED-2150: Add PAT auth support to Rust API client

[tausman]

PR Stack

API Client Libraries (closed)

All client libraries except Rust already support PATs via the existing OAuth/AuthZ code path. No new changes were needed.

• Go: CRED-2147: Add PAT auth support to Go API client datadog-api-client-go#3764 — CRED-2147 — PATs work via existing OAuth code path
• Python: CRED-2146: Add PAT auth support to Python API client datadog-api-client-python#3243 — CRED-2146 — PATs work via existing OAuth code path
• TypeScript: CRED-2148: Add PAT auth support to TypeScript API client datadog-api-client-typescript#3588 — CRED-2148 — PATs work via existing OAuth code path
• TypeScript v2: CRED-2148: Add PAT auth support to TypeScript v2 API client datadog-api-client-typescript#3610 — CRED-2148 — PATs work via existing OAuth code path
• Java: CRED-2149: Add PAT auth support to Java API client datadog-api-client-java#3555 — CRED-2149 — PATs work via existing OAuth code path
• Ruby: CRED-2151: Add PAT auth support to Ruby API client datadog-api-client-ruby#3058 — CRED-2151 — PATs work via existing OAuth code path

Rust: The Rust client generator does not support OAuth/AuthZ, so PATs cannot be used through the client library today. When OAuth/AuthZ support is added to the Rust generator in the future (#1438 has the approach), PATs will work automatically.

OpenAPI Spec Changes

• https://github.com/DataDog/datadog-api-spec/pull/5164 — CRED-2275: Add PAT/SAT management API endpoints

---

Why

Add Personal Access Token (PAT) authentication support to the Rust API client (CRED-2150). PATs allow authenticating via an Authorization: Bearer <PAT> header, providing an alternative to the traditional DD-API-KEY + DD-APPLICATION-KEY header pair.

Behavior

• When DD_BEARER_TOKEN is set (or set_pat() is called), the Authorization: Bearer <token> header is sent alongside any configured API key and app key headers.
• Auth methods are NOT mutually exclusive — all configured credentials are sent, and the server uses whichever is valid.
• DD_BEARER_TOKEN aligns with the OpenAPI spec's bearerAuth security scheme (x-env-name: DD_BEARER_TOKEN).

Commit structure

This PR has 2 commits for easier review:

1. CRED-2150: Add PAT auth support - templates and tests — Template changes (.generator/src/generator/templates/*.j2) + integration tests (tests/configuration_test.rs). Review this commit.
2. CRED-2150: Regenerated client code from templates — All generated files in src/ (132 files). Large diff produced by the generator — can skip review.

Summary of changes

• Generator templates (api.j2, configuration.j2): Bearer auth support is spec-driven — conditioned on bearerAuth being present in the OpenAPI securitySchemes, with the env var name read from x-env-name. No hardcoded env var names.
• Configuration struct (src/datadog/configuration.rs): Added pat: Option<String> field, set_pat() method, and auth_headers() method that returns all configured auth headers (bearer + API key + app key).
• All generated API files (131 files): Replaced inline per-scheme auth header insertion with a centralized configuration.auth_headers() call.
• DD_BEARER_TOKEN env var: When set to a non-empty value, the bearer token is included in requests. An empty value is ignored.
• Tests moved from generated configuration.rs to tests/configuration_test.rs so they survive regeneration.

Test plan

• 6 integration tests covering set_pat(), auth_headers(), env var handling, and coexistence of bearer + API key auth
• Live verification against staging (api.datad0g.com) using Authorization: Bearer with a real PAT
• Template changes are spec-driven (no hardcoded env var names)

[tausman]

Closing: PATs work via existing OAuth/AuthZ code path in all other client libraries. The Rust client lacks OAuth/AuthZ support in its generator, which is a separate gap. See #1438 for the future OAuth approach.