fix(core): stop forks from replaying superseded instructions - #61551

One thing this leaves in place: the fork still takes the parent's newest values as its baseline. Whenever the parent had an instruction update, the fork's system prompt differs from the one the parent's history was cached with, so the fork's first request writes the whole conversation to the prompt cache again.

An alternative that fixes the same contradiction and keeps the cache: start the fork from the parent's baseline and keep the copied updates, which then stay valid, and restate whatever changed after the copy at the tail. The fork's prompt then matches the parent's cached prefix. The same idea covers the undo case in #62027. The change is here: dev...swf-cmd:opencode-upstream:fork-instruction-baseline

I can't open it as a PR right now because I'm at the repository's open-PR limit, but I'm happy to once maintainers say which direction they prefer.

@swf-cmd Thanks, preserving the cached prompt prefix makes sense. I checked your alternative at 44fff3b with the runner harness and found two boundaries where the next request still contains a stale notice without a corrective update:

• A → B → A, then a historical fork that copies the B notice but excludes the later A notice. The inherited state falls back to A, so observing A emits no update even though B remains in the request.
• A → B → C, then a native checkpoint, followed by a fork before that checkpoint that still copies B. The fork inherits baseline C, but the checkpoint is absent and B is replayed without a C correction.

I added the A → B → A case and the checkpoint case in 192ba5d8. Both pass here; the four related test files pass (298 tests), each new case passes 10 repetitions, and bun run check passes.

Keeping the prefix looks worth pursuing, but the tracked state needs to match what the retained notices actually express, including the applicable instruction epoch, before computing the next delta.

AI-assisted testing and analysis.

You're right on both, thanks for running them. In the A → B → A case the fork falls back to A while the copied B notice is still in the request. Before a checkpoint it takes the post-checkpoint baseline, which the copied history was never sent with, so B again goes uncorrected.

Keeping the prefix would need the fork to rebuild its state from the copied notices on the baseline of the epoch they belong to, and instruction_state only keeps the current epoch's baseline. That's a bigger change than this fix, so please treat my alternative as withdrawn; it shouldn't hold this PR up. If I come back to keeping the prefix, it'll be a separate follow-up after this lands.