Entity operations don't propagate trace context from parent orchestration

[cgillum]

Summary

When an orchestration calls an entity via CallEntityAsync(), the DTS SDK does not propagate the orchestration's trace context (ParentTraceContext) to the entity operation. This causes entity spans (and any child spans created within the entity) to appear as disconnected root traces instead of being parented under the calling orchestration's trace tree.

Root Cause

In ProtoUtils.ConstructOrchestratorResponse, ParentTraceContext = CreateTraceContext() is set for:

• ✅ ScheduleTaskAction (activities)
• ✅ CreateSubOrchestrationAction (sub-orchestrations)
• ❌ SendEntityMessageAction — no trace context is set

This means the W3C traceparent / tracestate that enables distributed trace stitching is never included in entity messages dispatched from orchestrations.

Expected Behavior

Entity operations dispatched from an orchestration should inherit the orchestration's trace context, just like activities and sub-orchestrations do. The invoke_agent spans (or any other work done inside the entity) should appear as children of the orchestration span in a trace viewer.

Actual Behavior

Entity operations start a new, independent trace. In a trace viewer (e.g., Aspire Dashboard, Jaeger), entity spans appear as separate root traces with no parent relationship to the orchestration that dispatched them.

Impact

This is particularly impactful for scenarios that use Durable Entities as the execution model for agent invocations (e.g., DurableAIAgent in the Microsoft Agent Framework). Each invoke_agent span appears disconnected from the orchestration trace, making it impossible to view the full execution tree in a single trace.

Suggested Fix

In ProtoUtils.cs, add ParentTraceContext = CreateTraceContext() to the SendEntityMessage action construction (similar to how it's done for ScheduleTask and CreateSubOrchestration). The entity work item processing path would also need to parse and restore this context when executing entity operations.