fix: separate OTel provider provisioning from span generation

[ss1909]

Description

Problem

setupLoggerAndConfig only initialised the OpenTelemetry TracerProvider when TRACEPARENT was set in the environment. This was unreliable: TRACEPARENT is injected into every subprocess the agent spawns (git, bootstrap, hooks) so its presence is not a reliable signal that the current process is a traced subcommand.

This also caused a double-initialisation bug in the bootstrap flow: setupLoggerAndConfig created one provider, and startTracingOpenTelemetry created a second, loosing the first one.

Fix

Separate the two concerns:

• setupLoggerAndConfig always initialises the provider when BUILDKITE_TRACING_BACKEND=opentelemetry, and owns its lifecycle (ForceFlush + Shutdown in done())
• startTracingOpenTelemetry uses otel.GetTracerProvider() to obtain the already-registered provider and only creates the root job span, adding job-specific attributes (pipeline slug, job ID, etc.) at span level rather than resource level since they are not available at provider init time

Context

Changes

Testing

• Tests have run locally (with go test ./...). Buildkite employees may check this if the pipeline has run automatically.
• Code is formatted (with go tool gofumpt -extra -w .)

screenshots on grafana to show the subcommands:

Disclosures / Credits

[zhming0]

LGTM ✅ with some nits. Well done 👍🏿