[Feature]: Allow forking a thread while the source session is still working

[ImBIOS]

[Feature]: Allow forking a thread while the source session is still working

Forking a thread whose provider session is mid-turn fails hard with:

opencode provider protocol error: Cannot fork OpenCode session while it is still working.

Real incident: a fork created ~13 seconds after its parent's run started died in ~2s at provider-turn start. Nothing was wrong with the fork point (an earlier completed run) — the guard in ensureQuiet (packages/provider-opencode/src/server/v2/adapter.ts) refuses to cut/copy history while anything writes to the session, so the only remedy today is "wait for the source to go idle and retry".

Why the guard exists is understandable (forking a moving history risks corruption), but the failure mode is bad: the fork's run is marked failed, and a user who just wants to branch off already-settled work has to poll the source thread.

Desired behavior: fork at the last settled history boundary (or queue the fork until the session goes idle) instead of failing. Notably, PR #19986 ("forking an earlier turn while the thread runs no longer fails") already implements exactly this — fork at the earliest eligible settled native-history boundary with a bounded wait and actionable retry advice — but it is still open awaiting review. This discussion tracks the feature request: please land #19986 (or equivalent) so forks off settled work succeed while the source keeps running.

[ImBIOS]

Refining the proposal with a better UX option: queue the fork instead of failing.

When the source session is still working, accept the fork immediately and put its run in a visible waiting state ("Waiting for source turn to finish…") rather than marking it failed. Execute the fork the moment ensureQuiet passes — the user just waits, no retry polling, no failed-run stigma.

Details worth getting right:

• Settle first when possible. If the fork point's prefix is already settled (the common "branch off earlier work" case), fork at that boundary right away like fix(opencode): forking an earlier turn while the thread runs no longer fails #19986 does — only genuinely-moving histories need the queue.
• Bound the wait, visibly. Mirror existing run timeouts: show a countdown and offer Cancel. On timeout, fall back to the actionable retry advice fix(opencode): forking an earlier turn while the thread runs no longer fails #19986 already produces. A fork that waits forever with no feedback is barely better than an error.
• Don't hold effect workers while waiting. fix(opencode): forking an earlier turn while the thread runs no longer fails #19986's own limits note flags this: four simultaneous waiting forks could occupy all four effect workers for the wait duration. The queue should live at orchestration level (wake on session-idle event) rather than parking a worker per waiting fork, or cap concurrent waiting forks with a clear "queued behind N forks" indicator.
• Cancel must actually cancel. fix(opencode): forking an earlier turn while the thread runs no longer fails #19986 notes Stop-during-wait can leave an unused native fork behind; a queued design should make cancel cheap since nothing has started yet — another argument for queue-at-orchestration over wait-inside-effect.