Fix SageMakerTransformOperator succeeding on a failed deferred job

[steveahnahn]

Problem

SageMakerTransformOperator with deferrable=True (which is the default whenever a deployment sets [operators] default_deferrable=True) can mark a task successful even though the SageMaker batch-transform job failed. The failed job's description is pushed as the XCom result, so downstream tasks run against missing/invalid transform output with no error surfaced.

Root cause

The operator defers while the job is still InProgress, so the job can fail during the deferred wait. The trigger is SageMakerTrigger, which since #68927 inherits AwsBaseWaiterTrigger.run(). On waiter failure that base yields TriggerEvent({"status": "error", ...}) instead of raising — so execute_complete is resumed with an error event. SageMakerTransformOperator.execute_complete never checked the status: it logged "SageMaker job ... completed." and returned serialize_result(...), so the task succeeded.

Every other SageMaker operator's execute_complete already guards this (if status != "success": raise). Transform was the only one missing it. Before #68927 the previous trigger raised on failure, so the missing guard was dormant; migrating to the yielding base class turned it into a live silent-success.

Fix

Reject a non-success status in SageMakerTransformOperator.execute_complete, matching the sibling operators, and add a regression test (a deferred transform that fails during the wait now fails the task instead of reporting success).

Note on the exception type: the sibling operators raise AirflowException, but the check-no-new-airflow-exceptions hook forbids new raise AirflowException usages, so this raises RuntimeError (identical task-failure/retry semantics, and already used elsewhere in this provider, e.g. dms.py).

---

Was generative AI tooling used to co-author this PR?

• Yes — Claude Code (Opus 4.8)

Generated-by: Claude Code (Opus 4.8) following the guidelines

[SameerMesiah97]

Approved pending green CI.

I think this PR exposes an underlying issue in AwsBaseWaiterTrigger.run(); the state machine for the SageMaker transform job has been simpliefied to just 2 possible states i.e "success" and "error", when I would imagine there can be more states for failure, cancellation, timeout etc. However, fixing that would involve overriding the parent run method with a customized run method in SageMakerTrigger, which is beyond the scope of this PR. A follow-up PR exploring this may be justified.