Auth config documentation

When Helm (or other config) controls authentication for a protected endpoint, treat credential source, key names, and auth enablement paths as security-sensitive behavior. Ensure both the implementation and the accompanying docs/changelog precisely describe:

• Auth enablement outcome: what happens to unauthenticated requests (e.g., 401 leading to Prometheus up=0).
• Credential inheritance vs explicit override:
  • Default behavior should state whether credentials and their key names are inherited from an auth configuration.
  • Any existingSecret/override should state that it fully overrides inherited secret identity and key mapping (i.e., keys come from the override’s usernameKey/passwordKey, not from the auth config’s key names).
• Validation step: verify documentation claims by inspecting the rendered output (e.g., via helm template) and confirming the exact Secret names and key fields.

Example validation approach:

helm template rel . \
  --set serviceMonitor.enabled=true \
  --set serviceMonitor.basicAuth.enabled=true \
  --set serviceMonitor.basicAuth.existingSecret=scrape-creds \
  --set bifrost.authConfig.existingSecret=bifrost-secrets \
  --set bifrost.authConfig.usernameKey=admin-username \
  --set bifrost.authConfig.passwordKey=admin-password

# Confirm rendered basicAuth uses scrape-creds with key names
# (e.g., username/password), not inherited admin-username/admin-password.

This prevents misleading security documentation that can cause operators to scrape with wrong credentials, misunderstand failure modes, or break credential rotation assumptions.