STS Basic auth header uses URL-safe unpadded base64 instead of RFC 7617 standard base64

Unconfirmed. This is the result of a search with Claude, may be a false positive.

In `src/auth/src/credentials/internal/sts_exchange.rs`, `ClientAuthentication::inject_auth` creates the HTTP Basic authentication header:

https://github.com/googleapis/google-cloud-rust/blob/f02b42c2ac5720334cd2b5335824bd4166264527/src/auth/src/credentials/internal/sts_exchange.rs#L190-L191

The code uses `base64::engine::general_purpose::URL_SAFE_NO_PAD`. However, RFC 7617 §2 requires standard base64 encoding with padding (`=` characters) and standard alphabet (`+` and `/`).

Endpoints strictly adhering to RFC 7617 may reject Authorization headers encoded with unpadded URL-safe characters.

Start in src/auth/src/credentials/internal/sts_exchange.rs at ClientAuthentication::inject_auth and compare the current Authorization encoding with RFC 7617 §2. Verify the resulting header uses the RFC-required Basic authentication encoding, including standard alphabet and padding, and confirm the affected STS exchange behavior.

Written by the indexing model from the issue text.