fix(core): widen run start-attempt retry to ride out transient connection blips - #4441

What

When a run starts, the run controller's first call is startRunAttempt. It already retried transient connection errors, but only on the default short budget (~5 attempts, ~7.5s) — too short to ride out a brief blip talking to the worker (e.g. the worker being briefly unreachable). When that budget was exceeded the start was abandoned and the run went back through the queue, delaying its first attempt.

This widens the retry budget on that one call to ~25-40s (jittered), matching the already-hardened continueRunExecution path, so a brief blip is ridden out in place instead of bouncing the run.

Budget & the 60s stall

For the case this targets — a genuine connection error (worker unreachable) — each attempt fails fast, so ~25-40s of backoff fits well inside the platform's 60s pending-execution timeout. The reachable-but-failing case is different: the worker maps an inner failure to a 500, and this outer retry (like continueRunExecution) also retries 5xx, so it stacks with the worker's own inner retry and can run past 60s. That's deliberate and safe — it degrades to the same requeue that happens today, and start-attempt is idempotent server-side (snapshot-id guarded), so a late retry after a committed start is rejected and never double-starts.

Why this belongs on the SDK side

The worker already retries its own hop inward, but that only helps once it has received the request. The case this fixes — the worker briefly unreachable (connection refused, e.g. a restart) — never reaches it, so only the run controller can retry. The two retries are complementary, on different hops.

Scope

One retry-options object on startRunAttempt; no other behavior change. Warm starts share this path and get the same resilience.