Implement feature negotiation for CI job telemetry (Rails side)
## Summary
Implement the Rails side of feature negotiation for CI job telemetry. When a Runner requests a job, the Rails response should include a `features.tracing` object that signals telemetry is enabled and provides trace context for that job.
## Job payload change
Add a `tracing` entry to the existing `features` object in the `/api/v4/jobs/request` response:
```json
{
"features": {
"tracing": {
"trace_id": "<hex-encoded 16-byte trace ID derived from root pipeline ID>",
"span_parent_id": "<hex-encoded 8-byte span ID of the trigger/bridge job, if child pipeline>",
"otel_endpoints": ["https://otel-collector.gitlab.net/v1/traces"]
}
}
}
```
- **Presence of `features.tracing`** = telemetry enabled; **absence** = telemetry disabled (no boolean flag needed).
- `trace_id` is derived deterministically from the **root** pipeline ID, so all jobs across parent and child pipelines share the same trace.
- `span_parent_id` is included only for child pipeline jobs and references the trigger (bridge) job's span ID, allowing child pipeline jobs to nest under the trigger job in the trace tree.
This is a unified payload — sampling configuration is not included:
- **Sampling** is handled entirely at the OTEL Collector level using the [probabilistic sampler processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/probabilisticsamplerprocessor), adjustable without Rails or Runner changes
- **The OTEL Collector endpoint** is provided from Rails via `features.tracing.otel_endpoints` (array, max 2) — first entry is a Rails application setting (see gitlab-org/gitlab#591941); optional second entry is a customer-configured BYO OTLP endpoint (project/group level, future). No static runner-side `config.toml` configuration needed.
## Requirements
1. Add `tracing` (with `trace_id` and optional `span_parent_id`) to the `features` object in the job payload response
2. Controlled by a **project-level feature flag** for gradual rollout
- MVC: enable for DevExp Customer0 projects on hosted runners
- Broader rollout: enable progressively for more projects
3. Include `trace_id` (derived from root pipeline ID) and `span_parent_id` (for child pipelines) inside `features.tracing` (see gitlab-org/gitlab#590587)
## Architecture Reference
- [Job payload changes](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/ci_job_telemetry/#job-payload-changes)
- [GitLab Runner changes](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/ci_job_telemetry/#gitlab-runner-changes)
## Related
- Trace context initialization (Rails): gitlab-org/gitlab#590587
- Runner-side implementation: gitlab-org/gitlab-runner#39231
- Coordinate with ~"group::runner core" on the payload schema
## Parent Epic
gitlab-org&20945
issue