[Feature]: Record execution exceptions on Workflow and Invocation spans

Start with the FAILED finalization branches in execution_plugin.py and invocation_plugin.py, then read the existing error-object event helper and coordinate the shared behavior through the RFC and linked conformance requirement. Add focused tests for both views and the specified failure and retry cases; done means the SDK and shared conformance checks verify exactly one correctly attributed exception event with the required status and timestamp behavior.

What would you like?

Record the execution exception on both the terminal Invocation span and the Workflow span, in both Execution and Invocation views, when an uncaught handler error makes the durable execution finish with FAILED.

A handler that raises RuntimeError("Intentional execution failure") before starting any durable operation currently produces two ERROR spans with a status description but no exception event. The same gap occurs in a chained-invoke target raising RuntimeError("Intentional chained-invoke target failure") outside any durable operation. In X-Ray, the target spans have fault: true but no cause.exceptions or original error message.

The existing public OTel cases otel-execution-19 / otel-invocation-19 and the targets of otel-execution-18 / otel-invocation-18 exercise these scenarios. A local check with the real InMemorySpanExporter, both plugins, and both error messages also produced ERROR, the correct status description, and events=[] for Workflow and Invocation.

Possible Implementation

InvocationEndInfo.error already supplies an ErrorObject containing the original type/message and any available stack metadata. Add standard exception recording to both spans' FAILED finalization branches using that supplied metadata. Reuse the existing error-object event helper, coordinated with #886, rather than constructing a generic exception that changes the original type or manufactures a stack.

Inspected at commit 44b9f4d1c862b50041423e19fe6a250bbf7bd72f:

• Execution view: Workflow finalization and Invocation finalization in the same file.
• Invocation view: Workflow finalization and Invocation finalization in the same file.

The omission is also present in the inspected 4625d01bbfa97da67050014851af7eb41c61a842 revision, which provides the shared record_error_object_exception helper for operation/attempt events.

Acceptance criteria

• Both views retain ERROR status and record exactly one SDK-generated exception event for the known execution failure on each terminal Invocation and Workflow span.
• Preserve the supplied exception type and original message, plus stacktrace when available. Missing stack metadata must not create a synthetic traceback; recovering frames not supplied by core is outside this request.
• Cover direct handler failure and the failed chained-invoke target. Assert the target's own span diagnostics independently of the caller's invoke span.
• Cover failure after a durable suspension and resume: completed work is skipped, one logical Workflow span is emitted only on terminal completion, and neither logical span gains duplicate exception events. Duplicate exports of the same span identity do not count as additional spans or events.
• A caught operation failure followed by successful handler completion keeps Workflow and Invocation successful without adding that caught error's exception. Existing operation/attempt diagnostics remain intact.
• Preserve PENDING/RETRYING status and export semantics. Use the final invocation outcome supplied to the hook, including cases where checkpoint-token loss converts a provisional failure into PENDING. Do not invent an exception when error details are unavailable.
• Keep event timestamps inside the corresponding spans and coordinate with the timestamp behavior in #853.
• Add focused SDK regression tests and satisfy the linked shared conformance requirement for both views and the supported OTLP/X-Ray representations.

Is this a breaking change?

No. This adds diagnostic events without changing handler behavior, public APIs, checkpoint contents, retries, or replay. Document the observable addition for telemetry consumers.

Does this require an RFC?

Yes, for agreement on the shared telemetry behavior and conformance expectations across SDKs.

Additional Context

The Java OTel implementation already records the execution error on Workflow and Invocation. This request defines the corresponding explicit contract for Python and JavaScript.

The shared conformance Span model currently has no exception-event representation, and its normalizers discard OTLP events and X-Ray cause.exceptions. ERROR-only assertions therefore cannot detect this gap. The associated requirement needs to extend that model/normalization and assert the exception details.

Related work: #853 covers operation/attempt terminal statuses and event timing; #886 covers stacktrace-presence semantics for supplied metadata. This request adds the missing execution-scope Workflow/Invocation events and their shared conformance coverage.

Shared conformance requirement: https://github.com/aws/aws-durable-execution-conformance-tests/issues/178

JavaScript counterpart: https://github.com/aws/aws-durable-execution-sdk-js/issues/1135