feat: add allowIterResume flag to chain sessions across iterations

[jomonkj]

Problem

Currently resumeSession is applied to iteration 1 only:

// Orchestrator.ts line 281
const iterationResumeSession = i === 1 ? options.resumeSession : undefined;

For multi-iteration runs (maxIterations > 1), iter 2..N start cold — discarding the warm prompt-cache from the prior iteration. This increases token cost on every iteration beyond the first.

Solution

Add an opt-in allowIterResume?: boolean flag to RunOptions and OrchestrateOptions. When true, each iteration's sessionId is chained forward as the next iteration's resumeSession:

// after the change
const iterationResumeSession = options.allowIterResume
  ? currentResumeSession   // chains from prior iter
  : i === 1 ? options.resumeSession : undefined;

// ...and after each iter:
if (options.allowIterResume && lifecycleResult.result.sessionId) {
  currentResumeSession = lifecycleResult.result.sessionId;
}

run() also relaxes its existing resumeSession + maxIterations > 1 guard when allowIterResume: true is set.

Behaviour

• Default (allowIterResume: false / omitted): exactly the same as before — no behaviour change.
• allowIterResume: true: iter N+1 receives iter N's sessionId as resumeSession. Requires maxIterations > 1 to have any effect.

Motivation

Filed on behalf of lbrmi/yard — a fleet orchestrator that runs Claude Code agents with multi-iteration implementer passes. We currently vendor a patched copy of Orchestrator.js; if this lands upstream the vendor can be removed.

[vercel]

@jomonkj is attempting to deploy a commit to the Matt Pocock's projects Team on Vercel.

A member of the Team first needs to authorize it.