[Fix] Fast tasks cannot recover from sandbox startup failures

[roomote-roomote]

​Opened on behalf of @mrubens. Follow up by mentioning @roomote-roomote or in the web UI.

What changed

• Give the Slack Fast parent the complete secret-redacted startup error and machine-readable error code from failed child tasks.
• Add a settlement-only retry_task_start action so the parent can decide whether the reported failure is worth another attempt.
• Reuse the existing failed-start eligibility checks, cap parent-requested relaunches at two attempts, and apply 1-second then 2-second backoff.

Why this change was made

Fast-delegated tasks previously stopped after a sandbox startup failure and required a manual restart. Their terminal lifecycle event omitted the recorded error and error code, so the parent could neither assess the failure nor request a safe relaunch.

Impact

The Fast parent now makes the retry decision from provider evidence instead of hard-coded error matching. Runtime safeguards still prevent retries after agent output, for unsupported task types, after two relaunches, or outside Fast child settlement events; other task paths are unchanged.

[roomote-community]

1 issue outstanding. See task

• Make Fast child-start retries atomic so concurrent retries cannot launch duplicate runs (packages/sdk/src/server/lib/task-runs/notify-fast-agent-parent-on-settle.ts:76).

_{Reviewed 4f0de56}

[roomote-roomote]

Updated the retry design: the Fast parent now receives the complete secret-redacted error and errorCode, decides whether to call retry_task_start, and runtime code only enforces eligibility, the two-retry budget, and 1s/2s backoff. Removed retry regex classification. Focused tests, package typechecks, changed-file lint, and the full pre-push suite pass.

Shipped in 96d7cd4. See task.

[roomote-community]

This check is not atomic with enqueueTaskRelaunch: two retry requests can both observe no child run and then each insert one, because task_runs.source_run_id has only a non-unique index and the enqueue path has no duplicate guard. A manual retry concurrent with the parent retry (or overlapping delivery) can therefore launch the same failed run twice, bypassing the intended two-retry budget and duplicating work. Move the idempotency guarantee into an atomic queue/database operation, such as a unique source-run constraint with conflict handling or a transaction/claim.

[daniel-lxs]

Reviewed the integrated retry path after #1435. Verified retry eligibility and budget enforcement, idempotent event redelivery, explicit action availability, and multi-task interaction. Local package suites and repository static gates pass; GitHub CI is green.