[Fix] Task deletion no longer leaks artifacts after storage failures

[roomote-roomote]

​Opened on behalf of @daniel-lxs. View the task or mention @roomote-roomote for follow-up asks.

What changed

Task deletion now aborts when artifact object deletion throws or reports failed objects. The transaction retains task and artifact metadata instead of committing a soft-deleted task whose remaining object-store keys can no longer be retried.

Focused regression coverage verifies that both reported batch failures and thrown storage errors occur before any artifact-row, task, parallel-count, or session mutation. The successful deletion path remains unchanged.

Why this change was made

The previous best-effort path deleted every taskArtifacts row even when S3 returned errors. That erased the only durable mapping to failed object keys and could permanently leak stored artifacts.

Impact

Users can retry task deletion after a transient or partial storage failure without leaving unreachable objects behind. The targeted task-deletion suite passes all 6 tests, and the web package type-check and changed-file formatting checks pass.

Related PRs

• Scheduler disable fence: [Fix] Disabled automations no longer launch from stale scheduler scans #2187

[roomote-community]

No code issues found. See task

_{Reviewed 317c082}