fix(core): retry run start-attempt on transient connection errors (#4441)

## What
`startRunAttempt` — the run controller's first call when a run starts —
had no retry on transient connection errors. A brief connection blip on
that call would abandon the start and send the run back through the
queue, delaying its first attempt.

This adds a jittered backoff retry, matching the existing
`continueRunExecution` path with a shorter budget, so a transient blip
is ridden out in place instead of bouncing the run.

## Why a shorter budget
The continue path retries generously. Start-attempt keeps a tighter
budget (6 attempts, ~25-40s jittered) so it rides out a transient blip
but never keeps retrying past the point the run would already have been
requeued.

## Safety
Retrying is safe: start-attempt is guarded server-side by the snapshot
id — a retry after a start has already committed is rejected, so it can
never double-start an attempt. A pure connection error (the common case)
never reached the server.

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

Author: nicktrn

.changeset/retry-run-start-on-connection-error.md

@@ -0,0 +1,5 @@
+---
+"@trigger.dev/core": patch
+---
+
+Transient connection errors when a run starts are now retried for longer, so a brief connectivity blip no longer sends the run back through the queue and delays its first attempt.

packages/core/src/v3/runEngineWorker/workload/http.ts

@@ -165,6 +165,15 @@ export class WorkloadHttpClient {
           ...this.defaultHeaders(),
         },
         body: JSON.stringify(body),
+      },
+      {
+        retry: {
+          minTimeoutInMs: 1000,
+          maxTimeoutInMs: 10_000,
+          maxAttempts: 6,
+          factor: 2,
+          randomize: true,
+        },
       }
     );
   }