[Bug]: OTel operation and attempt events lose the original exception.type #804

Expected Behavior

OpenTelemetry exception events on durable operation and attempt spans should preserve the original error type supplied by the SDK, including when using serialized error metadata. For example, ValueError, KeyError, and TimeoutError should remain distinguishable in exception.type.

Actual Behavior

Both OTel views construct a generic Exception from info.error.message or info.error.type and pass that object to span.record_exception. That changes the exception's runtime type to Exception, so the original type is lost from the automatically generated exception event even when info.error.type is available.

Public main at 1e1f0245ded2e7320e562b05c4699272c2edad1d contains this construction in all four paths:

• Execution view: operation and attempt.
• Invocation view: operation and attempt.

For example:

span.record_exception(
    Exception(info.error.message or info.error.type or "Unknown error")
)

Steps to Reproduce

This report is based on public source inspection. The following runtime validation recipe has not been executed for this report:

1. Configure one OTel view with a recording provider and an in-memory exporter, with sampling enabled.
2. Run a durable step that raises ValueError("example failure"), with retries disabled for a single terminal attempt.
3. Inspect exception.type on the attempt and completed operation exception events.
4. Repeat with KeyError and TimeoutError, then run the cases with the other OTel view configured separately.

Expected: the event type preserves the original type. The current source instead supplies a generic Exception to OpenTelemetry.

SDK Version

aws-durable-execution-sdk-python-otel, public main at 1e1f0245ded2e7320e562b05c4699272c2edad1d.

Python Version

Not applicable to source inspection; no runtime reproduction was run for this report.

Is this a regression?

Unknown; no last working version has been established.

Acceptance Criteria

• Preserve the supplied original error type in operation and attempt exception events in both views, with a defined fallback when type metadata is unavailable.
• Retain the original error message and any available original stack information rather than substituting metadata from a synthetic generic exception.
• Cover multiple exception types across both views and span kinds, plus a replay/resume path using stored error metadata. Completed user code must not rerun to recover the type.

Additional Context

The public #758 head a5e3acc70143d08826de12a29646d9fe9ec44b75 also retains the generic operation exception construction. Its status/replay work does not remove this construction.