feat(claude-code): add telemetry input for OTEL export with workspace attribution

[morganl-ant]

Problem

Claude Code ships an OpenTelemetry exporter for token usage, tool calls, session lifecycle and errors (https://docs.anthropic.com/en/docs/claude-code/monitoring-usage), but the module exposes no first-class wiring for it. Template authors who want telemetry have to know the env var names (CLAUDE_CODE_ENABLE_TELEMETRY, the OTEL_EXPORTER_OTLP_* family) and write their own coder_env blocks. More importantly there is no convention for how to correlate Claude Code telemetry with Coder's own audit logs and exectrace records, so even when both are exported they end up as two unjoined datasets.

Change

Adds a telemetry input that turns on CLAUDE_CODE_ENABLE_TELEMETRY and the standard OTLP exporter env vars in one place:

telemetry = {
  enabled       = true
  otlp_endpoint = "http://otel-collector.observability:4317"
  otlp_protocol = "grpc"
  otlp_headers  = { authorization = "Bearer ..." }
  resource_attributes = { "service.name" = "claude-code" }
}

When enabled, the module automatically appends coder.workspace_id, coder.workspace_name, coder.workspace_owner and coder.template_name to OTEL_RESOURCE_ATTRIBUTES. This gives a stable join key between Claude Code spans/metrics and Coder's audit log and exectrace events on workspace_id, so a platform team can answer "show me every shell command Claude executed in workspace X alongside the token spend for that session" without custom plumbing.

This is purely additive (coder_env resources behind count), defaults to disabled, and is independent of how Claude is launched, so it composes cleanly with the install-only direction in #861.

Validation

• terraform fmt, terraform validate, terraform test (19/19) pass
• bun test -t telemetry (2/2) pass: env vars are set with the expected values when enabled, and absent when the input is omitted

Disclosure: I work at Anthropic on the Claude Code team.

[DevelopmentCats]

@morganl-ant

Thank you for the contribution! Everything looks good to me, but the one thing we do need in this, is for the module version to be bumped. You can use the version bump script to do so. This would be a minor version bump.