Add environment-driven OpenTelemetry initialization

[mariusvniekerk]

Why

Kenn tools currently have to recreate OpenTelemetry provider, exporter, propagation, and shutdown wiring in each application. That makes standard environment-driven configuration harder to adopt consistently and leaves lifecycle/error handling up to every caller.

The standard autoexport fallback would also attempt OTLP export to localhost when no exporter selector is configured. That is a poor default for reusable CLI and developer-tool infrastructure, where telemetry should remain inert until the operator explicitly enables a signal.

Approach

Provide one app-neutral initializer for traces and metrics that preserves standard OpenTelemetry environment variables and native SDK option types. The only deliberate policy difference is that unset trace and metric exporter selectors mean off; explicit otlp, console, prometheus, and none values retain contrib behavior. Logs remain on the existing slog path.

Initialization registers globals only after all fallible setup succeeds, cleans up partial setup, and returns one shutdown function that attempts both providers without hiding either error.

Validation

• go build ./...
• go tool gotestsum --format pkgname-and-test-fails -- ./... — 583 passed, 2 expected skips
• go vet ./...
• golangci-lint run ./telemetry/... — 0 issues
• git diff --check

Repo-wide golangci-lint run ./... still reports three pre-existing findings in git/cmd and vector/sqlitevec; this change introduces no telemetry lint findings.

^{generated by a clanker}

[roborev-ci]

roborev: Combined Review (060e2f8)

The change is generally sound, but it misses standard OpenTelemetry environment resource configuration.

Medium

• telemetry/init.go:101 — Init combines caller-supplied resource options with resource.Default() but does not apply the SDK environment resource detector. As a result, OTEL_SERVICE_NAME and OTEL_RESOURCE_ATTRIBUTES are ignored, potentially exporting telemetry with an unknown/default service identity even when exporters are fully configured through environment variables. Add resource.WithFromEnv() before caller options so explicit WithResourceOptions values can override environment values, and add coverage for OTEL_SERVICE_NAME or OTEL_RESOURCE_ATTRIBUTES.

---

Reviewers: 2 done | Synthesis: codex, 5s | Total: 1m34s

[roborev-ci]

roborev: Combined Review (0eaa7da)

No issues found.

---

Reviewers: 2 done | Synthesis: codex | Total: 1m51s

[roborev-ci]

roborev: Combined Review (afc5e1a)

Code changes look sound overall, but one medium-severity dependency vulnerability should be resolved before merging.

Medium

• Default baggage propagation exposes services to CVE-2026-41178 — telemetry/init.go:158, go.mod:17

  Init globally registers autoprop.NewTextMapPropagator(config.propagators...). When no propagators are configured and OTEL_PROPAGATORS is unset, autoprop defaults to TraceContext plus Baggage. The pinned OpenTelemetry version (v1.43.0) is affected by CVE-2026-41178 / GHSA-5wrp-cwcj-q835, allowing oversized or malformed attacker-controlled baggage headers to amplify CPU, memory, and log usage in instrumented HTTP/gRPC services.

  Upgrade all go.opentelemetry.io/otel modules to v1.44.0 or later and use a compatible autoprop release. Until then, use an explicit safe default such as propagation.TraceContext{} and prevent exposed services from re-enabling baggage through OTEL_PROPAGATORS.

---

Reviewers: 2 done | Synthesis: codex, 9s | Total: 3m30s

[roborev-ci]

roborev: Combined Review (51bb1b2)

No Medium, High, or Critical findings were identified.

---

Reviewers: 2 done | Synthesis: codex, 6s | Total: 4m55s