Allow forking a session as a new session from a checkpoint (branch, not in-place rewind)

Workflow that has no clean answer today

After a productive brainstorming session that produced a few tickets, I wanted to:

1. Keep this session as an immutable snapshot I can revisit months later.
2. Continue new work from a few turns back in the same context, without polluting the snapshot.

Today's primitives don't cover this:

• /rewind is in-place / destructive — it mutates the same session file. The "preserve original + branch new" intent isn't expressible.
• claude --resume <id> lands at the end of the file. The moment I send a new message, the snapshot is gone.
• Manual copy to a new UUID-named file in the project's session directory doesn't work cleanly: sessionId is baked into every record ("sessionId":"..."), so the filename and the embedded ID would diverge. Behavior on resume is undefined.
• Manual backup to an external directory preserves the bytes but isn't directly resumable — restoring it later would overwrite any progress the live session has accumulated under the original UUID since the rewind point.

What I'd love

A /fork (or /branch) command that:

• Takes a checkpoint (same picker UX as /rewind).
• Creates a new session ID seeded from the chosen checkpoint.
• Leaves the original session untouched.
• Drops me into the new session.

Equivalent CLI form: claude --resume <id> --fork-from <checkpoint>.

Bonus: a "pin / mark as snapshot" annotation that lets a session show up in --resume listings with a label, so the bookmark survives garbage collection of old project sessions.

Why this matters

The "use the session as a starting template for related future work" pattern is genuinely common — design reviews, brainstorming that spawns multiple follow-ups, debugging sessions you want to come back to. Today the workaround is OS-level file backup, which is brittle and requires understanding the JSONL format and project-dir conventions.