fix(otel): RETRY->UNSET status, workflow INTERNAL

[SilanHe]

Issue #, if available:

Description of changes: Invocation span status now maps RETRY->UNSET (was ERROR); the plugin interface cannot distinguish STOPPED/TIMED_OUT, so a RETRY invocation is not a definitive execution failure. Workflow span now sets explicit SpanKind.INTERNAL. Applied to both plugins; tests updated.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[github-actions]

Codex AI review

• [P2] Preserve RETRY as an invocation error — packages/aws-durable-execution-sdk-python-otel/src/aws_durable_execution_sdk_python_otel/execution_plugin.py:310, packages/aws-durable-execution-sdk-python-otel/src/aws_durable_execution_sdk_python_otel/invocation_plugin.py:360. RETRY explicitly means the invocation failed and is synthesized when an exception escapes the handler. Leaving these invocation spans UNSET hides retryable failures from error dashboards and alerts. Keep RETRY in the ERROR branch; only the nonterminal workflow span should remain UNSET.

Reviewed commit 323992edd79dcbed987a6e17a106d7f83b574546. Workflow run

[github-actions]

Claude AI review

No actionable findings.

I reviewed the full diff for PR #592 (head 323992e) across the four changed files:

• execution_plugin.py — explicit kind=SpanKind.INTERNAL on the workflow span + RETRY dropped from the ERROR branch.
• invocation_plugin.py — RETRY dropped from the ERROR branch.
• test_execution_plugin.py / test_invocation_plugin.py — parametrized expectations updated to RETRY → UNSET.

The change is correct and internally consistent:

• InvocationStatus has exactly four members (SUCCEEDED, FAILED, PENDING, RETRY). After the change the branches cover SUCCEEDED/PENDING → OK and FAILED → ERROR, with RETRY intentionally falling through to the default UNSET. No status is left unhandled.
• The durable.invocation.status attribute is still set unconditionally, so a RETRY invocation remains observable via the attribute even though the span status is now UNSET — this matches the stated rationale (STOPPED vs TIMED_OUT is indistinguishable at the plugin boundary).
• Both plugins are updated symmetrically and both test suites are updated to match, so the behavior change is covered.
• SpanKind.INTERNAL is already OTel's default for Tracer.start_span, so adding it explicitly to the workflow span is a no-op behaviorally (documentation/clarity only); the absence of a dedicated workflow.kind is INTERNAL assertion is therefore not a gap.

Residual test risk: minor. There is no direct test asserting the workflow span's kind, but since INTERNAL is the OTel default the assertion would pass trivially regardless of the diff, so its absence does not reduce coverage of the actual change.

Reviewed commit 323992edd79dcbed987a6e17a106d7f83b574546. Workflow run