Serial authored LLM branches can bind follow-up run IDs differently on resume #674

Reproduction

An authored serial root starts two async branches under Promise.all. Each branch awaits f.llm, then calls f.run with a distinct command. Delay the left LLM response by about 900 ms so the right branch declares its f.run first. Pause the run after both commands have completed, kill the CLI and daemon, then resume. The memoized LLM responses can settle in the opposite order. Resume may bind run-3 to the other branch's command and fail with run_admission_conflict.

const left = async () => {
  await f.llm('left', options);
  await f.run('printf L >> effects');
};
const right = async () => {
  await f.llm('right', options);
  await f.run('printf R >> effects');
};
await Promise.all([left(), right()]);
await f.run('test -f release || { touch stalled; sleep 120; }; printf Z >> effects');

The serial kind-N step ID counter assigns follow-up IDs in completion order. The order can change after restart even though both LLM results are durable.

Evidence

The #667 adversarial review reproduced the delayed-left variant (K4L/H1L) with a conflict on 6/6 resumes on published 2.0.50, main 2.0.51, and the parallel f.run draft. Delaying the right LLM instead (K4R) passed 6/6. This is a pre-existing serial scheduler issue, separate from #667's parallel identity work. No duplicate effect was observed in this scenario; the run fails closed.

Desired behavior

Resume should bind each completed effect to the same branch and step identity regardless of LLM completion order. Add a live regression test with two memoized LLM branches and a restart, including the delayed-left case.