Potential bug in propagation of OpenTelemetry

While working on https://github.com/typelevel/natchez/pull/1185 I checked if OpenTelemetry backend suffers from the same issue and it appeared it doesn't but I've spotted suspicious use of Context.current() like here and other places:

https://github.com/typelevel/natchez/blob/784ddf9d017c31e94f58d83a8049067f9a1d429d/modules/opentelemetry/src/main/scala/natchez/opentelemetry/OpenTelemetrySpan.scala#L214-L218

Since Context.current() is implemented using ThreadLocal, with cats-effect this would return effectively random context.

According to extract documentation it will merge information extracted from the kernel with passed in context.

So the spanId/traceId will be correct but there is a risk of polluting context with other information from wrong thread (maybe coming from instrumentation agents or third party Java code that uses otel?).

Not sure how important this is in practice but I think Context should be propagated with OpenTelemetrySpan, created with Context.root() in entrypoints and also activated in https://github.com/typelevel/natchez/pull/1189.

I don't really use it so I might be wrong.

Start with modules/opentelemetry/src/main/scala/natchez/opentelemetry/OpenTelemetrySpan.scala around lines 214-218, then review the OpenTelemetry Context.extract documentation and the entry points discussed in pull request 1189. Determine whether Context.current() can use unrelated thread-local state under cats-effect and whether context propagation needs correction; done means the behavior is verified and any resulting change is covered appropriately.