✨ add wasm coverage and trace context

docs/extend/index.md

@@ -10,5 +10,6 @@ Start from an [Example flow](../examples/index.md), then add one extension at a
 | Send records to multiple destinations or route by level | [Sink composition](./composition.md) | More explicit construction than presets. |
 | Control terminal appearance | [Text formatting](./formatting.md) | Formatting affects presentation, not record structure. |
 | Share code across native and web targets | [Target boundaries](./targets.md) | File and async runtime behavior differ by backend. |
+| Correlate logs with distributed requests | [Trace context](./observability.md) | Propagation and export stay application-owned. |
 
 For exact function signatures, follow each page's links into the [API reference](../api/index.md).

docs/extend/observability.md

@@ -0,0 +1,18 @@
+# Trace Context
+
+BitLogger keeps trace interoperability in its structured record model rather than owning HTTP propagation or a telemetry transport. Use the tracing library already selected by the application to extract a request context, then bind its identifiers to the logger.
+
+```moonbit
+let request_logger = logger.with_trace_context(
+  @log.trace_context(
+    trace_id,
+    span_id,
+    trace_flags="01",
+    trace_state=trace_state,
+  ),
+)
+```
+
+Every record from `request_logger` receives `trace_id`, `span_id`, `trace_flags`, and, when supplied, `trace_state`. The base logger is unchanged, so a child request cannot leak identifiers into unrelated work.
+
+Use `context.as_fields()` for a custom logger facade. BitLogger intentionally does not parse `traceparent` headers, create spans, make sampling decisions, or export OTLP data; those concerns remain with the application tracing implementation.