feat(tui): add Claude Code-style --fork-session flag to duplicate sessions before continuing (resolves anomalyco#11137)

[ariane-emory]

What does this PR do?

• Adds a Claude Code-style --fork-session CLI flag for session forking with --continue or --session
• Supports the same syntax that users of Claude Code are accustomed to in CC, to improve the comfort of those freshly converting from (or currently considering converting from) using CC to using OC.
• Forked sessions get the same automatic (fork #N) title suffixes via existing Session.fork() that forking via the /fork command or TUI message modal receive
• Validates that --fork-session is correctly paired with either --continue or --session
• Works with both the interacture TUI and opencode run commands
• Supports the use of a terse -F syntax in lieu of the verbose --fork-session (using a capital F so as to avoid collision with the --file option that is available in the context of opencode run)
• Graceful handling for edge cases (such as no session being available to fork) is included
• Applies to both attach mode and bootstrap mode

Resolves anomalyco#11137.

Supported syntax examples:

opencode --continue --fork--session
Start the TUI, continuing and forking (duplicating) the last session

opencode -cF
Same as previous, but using terse syntax for both switched

opencode run --continue --fork-session "tell me a better joke"
Run one prompt, continuing and forking (duplicating) the last session

opencode run --fork-session "tell me a better joke"
Same as previous, but using terse syntax for the --continue switch

opencode -F --session ses_3f2424a04ffeu0ZUiE12HfD2OI
Fork a particular session.

opencode -F --session ses_that_doesnt_exist
Fails gracefully: OpenCode starts, but displays a Failed to fork session toast.

opencode run -F --session ses_that_doesnt_exist "I'm not gonna work."
Fails gracefully: an Error: Session not found message is written to STDERR and an exit code of 1 is used.

Questions That Remain Open

Ought we tolerate --fork as being synonymous with --fork-session?

Forgetting to include the -session fragment does seem, to me, like a mistake that a user could easily make, so perhaps it would be prudent to give them a soft landing by accepting as a synonym.

This is not implemented presently, but this affordance would be trivial to offer, if it were desired.

How did you verify your code works?

Manual testing, bun test, bun typecheck: all pass with flying colours so far as I can tell thus far.

[IdrisGit]

while I get the spirit of the PR and it's a good way to help users migrating from CC to OC.

however what I am thinking here is that this might create two issues:

1. new users are not learning OC CLI and will start expecting OC CLI to have parody with CC CLI
2. it might not fit well with maintainers, as they are already facing issues with Anthropic and might not be open to maintaining parody with CC CLI.

what would be a better solution IMO:

1. create a plugin that achieves parody with CC CLI and those who want can use it.
2. do a chad move and whenever any user tried CC CLI, show help page with the OC CLI commands to achieve the same with a message this is not Claude Code

[ariane-emory]

@IdrisGit While we probably can't (and likely shouldn't try to) immediately take parity with every feature of Claude Code, this one seems to me to be an easy win where we can both provide (prospective and actual) CC converts with a feature they're accustomed to while simultaneously providing OC users with a genuinely useful feature. It seems like a modest first move in the grand project of giving Claude Code a wedgie and taking its lunch money: gotta start somewhere! The road towards checkmate almost always begins with pushing some pawns about.

I'm not entirely certain whether plugins can implement new command line switches for the opencode command - I would be somewhat surprised if they could.

When CC users ask "can I have my favourite Claude Code feature?, telling them "well, akshually, no you can't because we're OpenCode and we're different, get with the program!" doesn't seem like it's an answer that should satisfy either party. I think that it would be nice to take a step toward increasing the number of cases where we can say "yes, we have that feature too and ours is better" - that's an answer that would be much more satisfying to begin to be able to offer them!

[IdrisGit]

@ariane-emory I get your point, I am just thinking if this fit with OC maintainers, if they are fine with the fact that either they will have to reach parity with CC commands or have some of them, then it's fine, this is actually more natural for the users