Propagate trace context across gateway hops

Every hop was starting its own trace: a single end-to-end transaction through
LibreChat, Kong and the backends appeared in Tempo as a dozen unrelated traces,
one per service. Verified on twelve consecutive traces, each containing exactly
one service.

Kong receives a W3C traceparent -- it is visible in the http-log records -- but
without a propagation block it neither continues the caller's trace nor passes
one downstream, so it minted a fresh trace id per request and the backends did
the same.

extract lists w3c first with b3 and jaeger as fallbacks, since the callers here
are a mix of OTel SDKs; inject is w3c only, which is what the Python and Java
agents downstream expect.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

dataplane-globalpolicy-template/global-policies-plugins.yaml

@@ -103,3 +103,17 @@ config:
     service.name: ${NAME}
   sampling_rate: 1
   http_response_header_for_traceid: X-Trace-Id
+  # Without this block every hop starts its own trace: a single end-to-end
+  # transaction shows up in Tempo as a dozen unrelated traces, one per service.
+  # `extract` is what makes the gateway continue the caller's trace instead of
+  # opening a new one, and `inject` is what carries it to the upstream so the
+  # backend can continue it in turn.
+  propagation:
+    extract:
+      - w3c
+      - b3
+      - jaeger
+    inject:
+      - w3c
+    default_format: w3c
+    clear: []