Add pipeline/parent context to root execution span

[morgan-wowk]

Summary

execution.parent_id and execution.task_id are now emitted on the root execution span when an execution belongs to a parent pipeline run. This links individual execution traces to their parent pipeline run, enabling correlation with future pipeline-level business logic traces.

When parent_execution_id or task_id_in_parent_execution are absent, the attributes are omitted from the span entirely.

Screenshots

[morgan-wowk]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• Add CPU, memory, and accelerator resource requests to PENDING span #258
• Add pipeline/parent context to root execution span #257 👈 (View in Graphite)
• Add cache hit/miss context to root execution span #256
• Add launcher type and cluster URL to root execution span #255
• Add k8s pod/cluster attributes to PENDING status span #254
• Enrich error/success status spans with failure context #253
• Add retroactive OTel execution lifecycle tracing #252
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[yuechao-qin]

Is parent_id the upstream Node that the current execution node might be "WAITING_FOR_UPSTREAM" from?

Also,

    if execution.task_id_in_parent_execution is not None:
        attrs["execution.task_id"] = execution.task_id_in_parent_execution

wording is confusing for task_id_in_parent_execution, so is task_id going to be the current Node's ID or the parent's ID or something else?

[morgan-wowk]

🤖 Good questions — clarifying both:

• execution.parent_id is the ID of the parent graph/pipeline execution that spawned this child execution, not an upstream peer. WAITING_FOR_UPSTREAM refers to waiting on sibling tasks within the same graph whose output artifacts feed in as inputs — those are peers, not the parent.

• execution.task_id has been dropped from the span. The field name was confusing (it is the key this task has within the parent graph definition, e.g. "train", not an execution ID), and we only want to surface attributes that are shown in the UI. We do surface execution IDs, but not this task key. execution.parent_id is kept.