fix(sdk): export stable synthetic roots before suspension - #966

1. Add durable.execution.arn to DurableExecutionRoot (requested before merge)

createSyntheticRoot sets one attribute, durable.execution.synthetic_root (execution-plugin.ts:418, invocation-plugin.ts:394). The composed test pins that set with toEqual (synthetic-root-lifecycle.composed.test.ts:88).

1. Every other span these plugins create carries durable.execution.arn. That includes Invocation, Workflow and the operation spans.
2. So the root is the one span that a query filtered on the execution ARN does not return.
3. This PR's contract is that every copy of the root has identical span content.
4. Suppose a later release adds the attribute. An execution that runs across that deploy exports two copies with the same span ID. One has the ARN and one does not.
5. So adding the attribute later breaks the identical-copy contract for those executions.
6. Today the root exports only at terminal completion. So this PR is the last release where adding it costs nothing.

2. "No second sampler query for the anchor" holds only when the sampler wrapper is installed

The anchor is created through startSpan. startSpan routes through DurableSampler.withDecision only when tryInstallDurableSampler succeeded. That fails when the tracer does not expose _sampler, for example a wrapping tracer. In that case the provider's sampler is called for the anchor too.

I counted sampler calls per invocation for this sequence: first PENDING, resume PENDING, terminal SUCCEEDED.

The extra call is also visible in the output:

1. With no visible sampler, rootSamplingDecision returns RECORD_AND_SAMPLED (execution-trace-context.ts:251-253).
2. So the executionSamplingDecision guard in createSyntheticRoot passes.
3. Now take a sampler that rejects its first call and samples later calls.
4. Then the first PENDING invocation exports the root alone, and its Invocation child is dropped. On main that invocation exports nothing.

3. The README overstates how the terminal backup recovers a lost first flush

The anchor is gated on info.isFirstInvocation (execution-plugin.ts:271, invocation-plugin.ts:238).

1. Core sets isFirstInvocation only in ExecutionMode (with-durable-execution.ts:116).
2. Core selects ExecutionMode only when the operations array has at most one entry (execution-context.ts:100-103).
3. So a retry after the first invocation checkpointed a step runs in ReplayMode, and it creates no anchor.
4. I measured this sequence. The first invocation checkpoints a step, then is killed before its flush. The retry returns PENDING. The execution is then stopped while suspended. The result is 0 roots, on this branch and on main, in both views.
5. In that sequence, the retry's Invocation span points at the root span ID, which is never exported.
6. A plugin constructed before the global provider registers behaves the same way. Its first invocation has tracing disabled, so no anchor is created.

So two README sentences hold only conditionally:

• "This backup covers a first invocation that never reached its flush" (README.md:337) holds only if a terminal invocation runs later.
• "first-invocation retries can emit further copies" (README.md:335) holds only for retries that are still in ExecutionMode.

4. Copy policy: consider emitting the anchor on every sampled fallback invocation

The current policy emits the anchor on the first and terminal invocations only. For first PENDING, two resumes PENDING, then terminal, roots per invocation are [1,0,0,1]. On main they are [0,0,0,1].

The policy leaves three gaps:

1. The point 3 case: a lost first flush, then suspend, then stop or timeout. Result: 0 roots.
2. The late-registered global provider from point 3. Result: no root until terminal.
3. A sampler that samples only an intermediate invocation. That invocation's Invocation span has no exported parent. I measured 1 orphan span in both views, on this branch and on main.

Suppose the anchor were emitted on every sampled fallback invocation that has executionStartTimestamp. Then all three gaps close. Each extra copy is one zero-duration span with the same content as the others. Deduplication by span ID already has to handle the first-invocation retry copies this PR adds.

5. Document that descendants end after the root

The anchor starts and ends at executionStartTimestamp, so its duration is 0. Workflow and Invocation spans are its children, and they end later. In a three-invocation execution, every child ended after the root by up to the full execution duration. On main the root covered its children within 0.3 ms.

This is a consequence of exporting the root before the execution ends, and I agree with the trade-off. Some trace viewers and validators flag a child that ends after its parent. Suggestion: add one sentence to the README section. It should say that DurableExecutionRoot is a zero-duration identity span, and that its descendants end after it.

Thanks. I re-ran my probes against db3d8958, and all five points are resolved.

1. Both views put durable.execution.arn on DurableExecutionRoot. Across cold and warm retries, every copy is still identical in its SDK-owned fields.
2. When the sampler is hidden behind a forwarding tracer, sampler calls are [1, 1, 3] again. That matches main. The lone early root no longer appears.
3. The README wording on recovery matches the code.
4. A first invocation that is killed before its flush, followed by a replay-mode retry and then a stop, now leaves one exported root. Before this commit it left none. A late-registered provider and an intermediate-only sampled invocation both produce a root and leave no orphaned Invocation span.
5. The README documents the zero-duration root and its descendants ending after it.

The full OTel suite passes 456 of 456, and Biome and tsc --noEmit are clean.