codex-otel: add configurable trace metadata

[bbrown-oai]

Add Codex config for static trace span attributes and structured W3C
tracestate field upserts. The config flows through OtelSettings so
callers can attach trace metadata without touching every span call site.

Apply span attributes with an SDK span processor so every exported
trace span carries the configured metadata. Model tracestate as nested
member fields so configured keys can be upserted while unrelated
propagated state in the same member is preserved.

Validate configured tracestate before installing provider-global state,
including header-unsafe values the SDK does not reject by itself. This
keeps Codex from propagating malformed trace context from config.

Update the config schema, public docs, and OTLP loopback coverage for
config parsing, span export, propagation, and invalid-header rejection.

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[bbrown-oai]

I have read the CLA Document and I hereby sign the CLA

[owenlin0]

• Looks like a bad config value would prevent OTEL from initializing, "and in some binaries can fail startup" (according to codex). Can we just drop these new config values if they are not valid? And log a warning. I believe we have startup_warnings for that on config load.

• Separately, can we also add "otel" to PROJECT_LOCAL_CONFIG_DENYLIST? Recently I added config keys that repos shouldn't be able to inject, since people can create repos with malicious configs. I didn't add OTEL in that PR but now that I'm thinking about it, it will be good to do.

The current comment says project-local config should not choose “where a user's credentials are sent or which local commands are run” (loader/mod.rs (line 50)); telemetry endpoints and trace propagation markers fit that same class of environment/admin policy.

[owenlin0]

One small cleanup request: can we reuse the new validate_span_attributes() helper in OtelProvider::from() instead of keeping a separate empty-key check there?

That keeps the config sanitization path and the provider defense-in-depth path using the same validation logic, so we don’t end up with two sources of truth if span attribute validation grows later.