[Feature] OpenTelemetry GenAI exporter for Agent Traces (Phase 1: Java, spans-only)

[Zhuoxi2000]

Search before asking

• I searched in the issues and found nothing similar.

Description

Tracking issue for Phase 1 of the OTel exporter designed in #929 (direction confirmed by
@wenjin272 there; architecture points refined with @weiqingy), the follow-up to #900 agreed
with @joeyutong.

Scope (Phase 1):

• A batch, offline converter that reads already-collected Event Log files (written with
  event-log.trace.enabled: true) and maps recorded Execution Events ([api][runtime][python] Add Agent Trace recording to Event Log #924) to OpenTelemetry
  GenAI semantic conventions: one input run = one Trace with a synthesized invoke_agent root
  span; the execution hierarchy provides the Span topology; invoke_agent / execute_tool /
  chat span naming with gen_ai.* attributes; gen_ai.usage.* when recorded.
• Deterministic fixed-width ID derivation from the opaque framework IDs, so re-exports are
  idempotent to deduplicating backends (delivery itself is at-least-once).
• Configuration via plain converter arguments (endpoint, protocol, service.name); content
  capture excluded in Phase 1.
• Delivered as an optional standalone module, not bundled into dist, with OTel dependencies
  aligned via the opentelemetry-bom.
• The serialized Event Log is language-neutral, so one converter serves both Java and Python
  agents — no separate Python-parity phase.

Out of scope, tracked separately:

• A durable, replayable Event Log sink (e.g. a pluggable appender) and a continuous OTel
  consumer with checkpoint/replay semantics built on it.
• Content capture and richer usage enrichment (pending entityMetadata recording per the
  [Discuss][Observability] OpenTelemetry GenAI export for Agent Traces (follow-up to #900) #929 / [api][runtime][python] Add Agent Trace recording to Event Log #924 discussion).

Depends on #924 (recording contract).

Are you willing to submit a PR?

• I'm willing to submit a PR!