fix(v2/trace): warn when GITLAB_TRACING is set but not parseable

What this MR does

Logs a warning from trace.NewWithConfig when the GITLAB_TRACING environment variable is set but is not a valid v2 connection string. Previously the value was silently discarded, so the OTLP exporter fell back to the OTel SDK default of https://localhost:4318/v1/traces with no indication of why the configured endpoint was ignored.

The raw value is deliberately not logged because header_* query parameters may carry credentials. ParseTracingConfig and ParseTracingConfigFromEnv remain silent so callers using them as pure parsers are unaffected.

Why

Runway injects GITLAB_TRACING=opentracing://stackdriver?project_id=...&service_name=... (the legacy LabKit v1 format) by default. LabKit v2 only accepts otlp:// / otlps:// schemes, so every v2 service deployed to Runway hits this silent fallback and fails to export traces with an unexplained connection refused to localhost. This was diagnosed on a newly deployed Runway service today; the warning would have made it a 30-second diagnosis.

This MR fixes the observability gap in LabKit. Making Runway inject a v2-compatible default is a separate follow-up in the Runway project.

How to test

cd v2 && go test ./trace/

Or run any binary using v2/trace with GITLAB_TRACING=opentracing://foo and observe the startup warning.

🤖 Generated with Claude Code