[Enhancement]: Provide consistent environment-backed exporter headers across bindings

[bbednarski9]

Affected area

• Rust core runtime
• Python binding
• Node.js binding
• Go binding
• Plugins
• Observability or exporters
• Documentation or examples

Problem or opportunity

NeMo Relay supports header_env for some observability configuration paths, but the capability is not consistently available across public, programmatic exporter and subscriber configuration APIs. Applications that configure observability natively therefore lack a uniform way to source outbound exporter credentials from their deployment environment.

Proposed enhancement

Provide a coherent cross-binding header_env capability for public exporter and subscriber configuration surfaces that accept outbound headers. This should cover the appropriate OpenTelemetry and other observability exporter endpoints, while preserving the existing configuration-based support.

Runtime contract and binding impact

The Rust, Python, Node.js, and applicable Go public APIs should offer equivalent semantics for mapping a header name to an environment variable that supplies its value. The value is used only for outbound exporter authentication or routing; it must not become telemetry data, a resource attribute, or a runtime diagnostic.

Example scenarios

• A native SDK running in Kubernetes sends OTLP telemetry to a collector using credentials injected through a Secret.
• A hosted observability backend requires an API token and a tenant header that differ between deployments.
• CI, local development, and production use different collector credentials without changing checked-in application configuration.
• An ATOF or other observability archival endpoint needs deployment-specific authorization distinct from the application provider credentials.

Alternatives considered

Applications can resolve environment variables themselves and pass the resulting values through static headers. This works, but is inconsistent across bindings and makes declarative deployment configuration less portable.

Acceptance criteria

• Public observability exporter/subscriber configurations that accept headers have a documented, consistent environment-backed option where applicable.
• Supported bindings preserve the same user-visible semantics.
• Documentation explains intended secret-handling behavior and representative deployment scenarios.
• Tests cover the configuration contract without exposing secret values.