TUI rewind should preserve the current thread instead of forking by default

Problem

The TUI rewind/backtrack behavior now forks the conversation when editing
an earlier prompt.

This creates a new thread/session ID and leaves the original conversation
in the session history. Repeatedly correcting typos or fixing small mistakes
therefore produces many unwanted sessions.

More importantly, forking changes the session runtime state. For example,
background processes started by the original thread are no longer recognized
as being managed by the current thread after rewind. The process may still be
running, but the rewound session cannot reliably manage or clean it up.

This makes rewind unsafe for ordinary prompt correction.

Reproduction

1. Start a Codex TUI session.
2. Ask Codex to start a long-running background process.
3. Send several additional prompts.
4. Use rewind/backtrack to edit an earlier prompt, such as correcting a typo.
5. Continue in the rewound conversation.
6. Observe that:
   • a new thread/session is created;
   • the original thread remains in the session history;
   • the current thread loses access to runtime state associated with the
     original thread, including background process ownership/management.

Environment:

• Codex CLI: 0.151.0
• macOS arm64
• TUI

Expected behavior

Rewind used for correcting or replacing an earlier prompt should operate
in-place:

• preserve the existing thread/session ID;
• replace the durable conversation history with the prefix before the
  selected turn;
• preserve the current thread's runtime/session state, including background
  process management;
• avoid creating an additional user-visible session for every typo fix.

The current implementation should do the minimum necessary work to rewrite
the conversation history. It should not fork the entire session for a normal
rewind operation.

Proposed behavior

Use in-place thread/revert semantics for the default TUI rewind/edit flow.

If preserving the original conversation is desired, expose that as a separate
explicit operation such as "Branch" or "Try an alternative". That operation
can use fork + rewind semantics.

In other words:

• ordinary rewind/edit: in-place revert;
• explicit branch/alternative: fork, then rewind/edit in the fork.

The current behavior appears to come from:

• PR #33201:
  https://github.com/openai/codex/pull/33201
• Commit 469ce0db:
  https://github.com/openai/codex/commit/469ce0db51af87a09d44e24992dc655068d47e81

That change explicitly replaced in-place rollback with conversation forking,
but the resulting behavior causes session-history pollution and loss of
runtime state for the common typo-correction workflow.

Start by reviewing PR #33201 and commit 469ce0db, then trace the TUI rewind flow and its fork, rewind, and thread/revert operations. Done means ordinary rewind preserves the existing session ID and runtime state without creating a new session, while any explicit branching behavior remains separate.