ClusterWorkflowEngine drops trace context on persisted workflow requests

[roderik]

What happened

In Effect 4.0.0-beta.101, ClusterWorkflowEngine.sendDiscard constructs the persisted workflow Envelope.Request with Headers.empty but without traceId, spanId, or sampled from the current span.

The envelope protocol already supports these fields, SQL message storage persists them, and RpcServer uses them to re-parent the server span. The entity send path also forwards the current span, so workflow submissions are the inconsistent path.

Source evidence

• packages/effect/src/unstable/cluster/ClusterWorkflowEngine.ts: the internal sendDiscard call to Envelope.makeRequest omits the tracing fields.
• packages/effect/src/unstable/cluster/Envelope.ts: Request and makeRequest include optional traceId, spanId, and sampled.
• packages/effect/src/unstable/cluster/Entity.ts: keepAlive shows the intended cluster-envelope propagation shape.
• packages/effect/src/unstable/rpc/RpcServer.ts: server handling creates an external parent from the request tracing fields.

Expected behavior

ClusterWorkflowEngine.sendDiscard should read the current span and forward traceId, spanId, and sampled into Envelope.makeRequest, matching the entity/RPC path. A persisted workflow execution should therefore remain in the caller trace after crossing message storage and the runner boundary.

[pullfrog]

  ^{｜ Build this ➔ ｜ Make a plan ➔}