Stop premature sandbox aborts and offer retry on late failures

[mrubens]

Fixes the failure behind task 1e3wtt1oxrofl on the nightly.

What was happening

Sandbox creation was capped at three minutes (createInstanceTimeoutMs: 180_000, duplicated as a literal in all five spawn-*-worker modules). Under sandbox-creation rate limiting that deadline fires while creation is still queued, so the run is marked failed — and then the sandbox comes up anyway and the agent posts its work minutes later.

Measured on the nightly: run 3734 failed at exactly 3m00s after provision_started_at, and its assistant output arrived at 13:30, twelve minutes after the abort. A sibling run the same afternoon did the same eight minutes late, and a third failed outright with Sandbox creation rate limit exceeded. Over seven days, 4 of 42 failed runs produced real work after being declared failed — each one leaving the user an error banner sitting on top of a completed task whose thread is dead.

Changes

1. Creation deadline 3 min → 10 min, moved into a single shared timeouts.ts so it can be tuned once instead of five times. Bootstrap stays at 2 min — it runs after the provider has already returned the machine, so it is not subject to creation-queue contention. Waiting longer is the cheaper mistake: a slow start still shows the startup sequence, while a premature abort discards finished work.

2. Retry in the historical view. A start that fails before producing output shows the startup sequence's retry button; a run whose sandbox came up late lands in the historical view instead, which had no way to continue. It now offers the same retry, reusing the existing retryFailedStart command and useRetryFailedTaskStart hook. The eligibility predicate moved to @/lib/task-run-retry so the two views cannot drift apart.

Deliberately not changed

The relaunch allowlist. Run 3734's payload kind is github_pr_review_sync, which is not relaunchable — so this PR does not put a retry button on that specific task. Adding it would mean a retry re-runs a review that may have already posted, double-commenting on the PR. Worth deciding separately; the timeout fix is what prevents that class of task from failing in the first place.

Tests

Controller compute-providers 86 passed; startup 9 passed; HistoricalContent 8 passed including two new cases — a retryable failed start renders the button and fires the mutation with the right task/run ids, and a snapshot_resume failure renders no button (it has its own resume path). Repo type-check clean.

[roomote-community]

No code issues found. See task

• High apps/web/src/app/(sandbox)/task/[taskId]/HistoricalContent.tsx:62 The new retry is shown specifically for failed runs with late transcript output, but enqueueTaskRelaunch rejects any failed run with a non-kickoff task message. Clicking it in the intended historical case only shows an error, so this recovery path cannot succeed.
• Medium apps/web/src/app/(sandbox)/task/[taskId]/HistoricalContent.tsx:70 messages.length === 0 also hides Retry for failed chat-launched runs that contain only the provider kickoff message. The server deliberately accepts kickoff-only history, so these historical failures remain retryable but no longer expose the recovery control. Preserve the kickoff source in the client or derive eligibility server-side instead of treating every transcript item as agent work.

_{Reviewed f7819cb}