Send CI/CD OTel data with optional bearer token

What does this MR do and why?

Adds optional bearer-token authorization to the CI/CD pipeline OpenTelemetry export, and switches the export to the HTTPS OTLP endpoint for everyone.

When a user adds a GITLAB_OBSERVABILITY_TOKEN CI/CD variable (project or group), GitLab sends its value as an Authorization: Bearer <token> header on the pipeline OTLP export to the GitLab Observability (o11y) collector. When the variable is not set, the export is sent without an Authorization header exactly as today — so token auth is a no-op until a user opts in.

This supports GitLab Observability instances that enforce bearer-token authorization on their OTLP ingest: the user generates a token in o11y and pastes it into a CI/CD variable, and their pipeline telemetry authenticates.

HTTPS for everyone

This MR also switches the pipeline OTel export from the plaintext HTTP endpoint (otel_http_endpoint, http://…:4318) to the HTTPS endpoint (otel_https_endpoint, https://…:14318). This applies to all pipeline OTel exports, not just those that set a token.

The immediate driver is not exposing the new bearer token in transit, but the change is a general security improvement: pipeline telemetry (which can include repository, pipeline, and user metadata) is now sent over TLS for every project/group using the export, going forward.

How

• Ci::Observability::ExportService now reads GITLAB_OBSERVABILITY_TOKEN from the pipeline's scoped CI/CD variables (the same resolution path already used for GITLAB_OBSERVABILITY_EXPORT, so it respects project-level overrides) and returns { 'Authorization' => "Bearer <token>" } from otel_headers when present. The existing OtelExporter already merges otel_headers into the request headers, so no exporter change was needed.
• Variable resolution was extracted into a memoized scoped_variables so the export-type and token lookups share one resolution.
• The token value is rejected if it contains control characters, to prevent header injection via a malformed CI/CD variable.
• otel_endpoint_url now uses observability_settings.otel_https_endpoint.

Safe rollout

• No token behavior change for anyone who hasn't set the variable — no Authorization header is added.
• Users can add the token before their o11y instance enforces auth (the collector ignores it until enforcement is on), matching the recommended safe-rollout sequence.
• The HTTPS switch changes the endpoint (port 14318, TLS) for all existing exporters. o11y instances already serve OTLP over HTTPS on this port.

Screenshots or screen recordings

N/A (backend + docs only).

How to set up and validate locally

1. On a project/group with a GroupO11ySetting, add a CI/CD variable GITLAB_OBSERVABILITY_EXPORT=traces and GITLAB_OBSERVABILITY_TOKEN=<token> (masked).
2. Run a pipeline; on completion Ci::Observability::ExportWorker fires.
3. Confirm the OTLP request goes to the HTTPS endpoint and carries Authorization: Bearer <token>. Remove the token variable and confirm the header is absent (request still HTTPS).

MR acceptance checklist

• Tests added (spec covers header present/absent, whitespace trim, blank/no-build/control-char cases, and the HTTPS endpoint).
• Documentation added (doc/operations/observability/ci_cd.md).
• No feature flag — token auth is gated by the user opting in via the CI/CD variable; the HTTPS switch applies to all exports.