Fix concurrent span event recording in OTel shim

[Meemaw]

What Does This Do

Makes span-event handling in the OpenTelemetry shim (OtelSpan) thread-safe.

Span events were stored in a plain ArrayList that addEvent() / recordException() mutated without synchronization, and that onSpanFinished() iterated at span finish. When events are recorded from multiple threads (e.g. GraphQL DataLoaders running on virtual threads) while the span is being finished on another thread, the backing list gets corrupted, leaving a null hole that triggers a NullPointerException in OtelSpanEvent.toTag:

java.lang.NullPointerException: Cannot invoke
  "datadog.opentelemetry.shim.trace.OtelSpanEvent.toJson()" because "event" is null
    at datadog.opentelemetry.shim.trace.OtelSpanEvent.toTag(OtelSpanEvent.java:53)
    at datadog.opentelemetry.shim.trace.OtelConventions.setEventsAsTag(OtelConventions.java:143)
    at datadog.opentelemetry.shim.trace.OtelSpan.onSpanFinished(OtelSpan.java:182)
    at datadog.trace.agent.core.DDSpan.finishAndAddToTrace(DDSpan.java:162)

That NPE escapes span finish and can surface to the application as a request failure (observed in production as a jakarta.servlet.ServletException → HTTP 500 on a request whose spans were otherwise healthy).

Motivation

A tracer-internal data race should never turn into an application-visible error. This was hit in production on a Spring Boot + GraphQL service using virtual threads, where DataLoaders record span events concurrently on a span that is then finished from a completion callback.

Change

• All event-list mutations go through a private synchronized void addEvent(OtelSpanEvent).
• onSpanFinished() copies the list under the lock and serializes the private snapshot, so iteration can never observe a concurrent mutation.
• events is volatile so onSpanFinished() keeps a lock-free fast path (a single volatile read) for the common case of a span with no events — no monitor acquire and no extra allocation on the hot finish path. The lock/copy cost is paid only by spans that actually record events. Synchronization is on this, matching the OTel SDK's own SdkSpan, so no per-span lock object is allocated.

Testing

Added OpenTelemetry14Test.testConcurrentAddEvents (8 threads × 2000 events, then finish). It fails with the exact NPE against the current code and passes with the fix. The existing OpenTelemetry14Test suite remains green.