Ecs Task Stopped

EventBridge target — invoked when an ECS task in our cluster transitions to STOPPED. Marks any matching pipeline.job row as 'failed' with ECS's actual stoppedReason as the error message, and — whether the task exited cleanly or died — hands the job to settlement so a paid order whose check runs just finished settles in seconds instead of waiting for the sweep.

Replaces the polling-cron approach that PR #179 proposed (and closed). ECS publishes Task State Change events to EventBridge automatically; listening is strictly better than polling — seconds of latency vs. minutes, zero Fargate cost, and we get ECS's structured failure reason ("OutOfMemory", exit codes, etc.) instead of "ECS task stopped unexpectedly."

Idempotent and safe by construction:

• Tasks not matching any pipeline.job row → no-op (State GMs, Platform EM sessions live in the same cluster but have no row here).
• Jobs already in a terminal state → the row is left exactly as it is; only the settlement check runs, and it is itself idempotent.
• Events with lastStatus != STOPPED → ignored (the rule filters these out at EventBridge; this is defense-in-depth).
• EventBridge is at-least-once, so a replayed delivery re-runs both halves; neither bills or mutates twice.

The trigger-path sweep in has_running_job remains as a backstop for the rare case where an EventBridge delivery is lost, and the two-hourly stuck-order sweep remains the backstop for settlement.