observability: verify trace context survives enqueue to execute #854

The claim worth making is "a trace that starts in a Python request, enqueues a job, and executes
it in a Node worker is one trace". Nobody else in this space can say that, because nobody else
has one engine under three languages.

The claim is not currently supportable. What exists:

• docs/content/docs/python/guides/extend/otel.mdx — one SDK, and it documents the middleware
  hooks rather than context propagation
• trace_id appearing in metadata in tests (crates/flexiq-core/src/worker/protocol.rs,
  sdks/java/.../ExecutorAttachTest.java) — which shows metadata survives the frame protocol,
  not that trace context is extracted, injected or continued

So the first task is not to market anything. It is to find out what actually happens:

1. does an SDK inject W3C traceparent at enqueue, in each of the three shells?
2. does the worker extract it and make the execution a child span, in each shell?
3. does it survive the paths that are not a direct enqueue — retry, workflow step, durable step
   resume after step.sleep, pub/sub fan-out, a dead letter replay?
4. does it survive the network doors — gRPC producer, gRPC executor, attach?

Then, per gap: implement or document. A cross-SDK propagation test in the polyglot suite
(ci-polyglot.yml is the only job where the three SDKs meet) is what turns this from a claim
into a guarantee.

Only after that does it go on the landing page.