[smoke-otel-tracing] api-proxy container does not receive OTEL env vars for tracing

[github-actions]

Summary

The smoke test workflow smoke-otel-tracing validates OTEL tracing support in the api-proxy sidecar (containers/api-proxy/otel.js). While the otel.js module itself loads correctly and its test suite passes (59/59 tests in otel.test.js + otel-fanout.test.js), the env vars required to actually enable/configure it are never forwarded to the api-proxy container.

Details

src/services/api-proxy-service.ts (which builds the Docker Compose service definition for the api-proxy sidecar) contains no reference to OTEL_EXPORTER_OTLP_ENDPOINT or GITHUB_AW_OTEL_TRACE_ID (or any other OTEL-related env var). As a result:

• Even when the host/workflow has OTEL configured, the api-proxy container never sees the endpoint or trace-parent context.
• otel.js's isEnabled() will always be false inside the container, so no spans are ever created or exported for proxied LLM requests.
• Confirmed via /tmp/gh-aw/otel.jsonl: only 1 span was present after a full run (gh-aw.agent.setup, from the workflow's own tracing), with zero spans originating from the api-proxy sidecar.

Expected

src/services/api-proxy-service.ts should forward relevant OTEL env vars (e.g. OTEL_EXPORTER_OTLP_ENDPOINT, OTEL_EXPORTER_OTLP_HEADERS, GITHUB_AW_OTEL_TRACE_ID/parent span context) into the api-proxy container's environment, similar to how other config is passed through, so that otel.js can initialize and export spans for GenAI request tracking.

Acceptance Criteria

• api-proxy-service.ts forwards OTEL env vars to the api-proxy container when configured
• api-proxy spans (with gen_ai.usage.* attributes) appear in exported traces alongside workflow spans
• Smoke test scenario "Validate OTEL env var forwarding" passes

📡 OTel tracing validated by Smoke OTel Tracing
_{Add label ready-for-aw to run again}

• expires on Aug 8, 2026, 10:40 PM UTC