Undo should expose a completed compaction boundary in TUI and Desktop/Web #41266

Description

A completed compaction must be undoable as its own history boundary. With this sequence:

user prompt → assistant work → completed compaction → later agent work

Current rollback can fall back to the preceding user message rather than the compaction. That rewinds past assistant output that existed before the compaction, so there is no way to restore the exact pre-compaction state.

This is related to #8689, but is the compaction-specific consequence: compaction is now a durable request, yet it is not consistently exposed as an undo target. It also regresses the practical resolution of #32368, where /undo could remove the compaction marker while keeping the preceding assistant turn.

Steps to reproduce

1. Use a session and send a prompt; wait for the assistant to finish work.
2. Run /compact and wait for compaction to complete.
3. Let the agent produce more work after compaction.
4. Invoke Undo or use the client's revert UI.

Expected behavior

Undoing a completed compaction should remove the compaction and subsequent work, while retaining all messages before the compaction, including the preceding assistant turn, and restore that history to active context.

This must be discoverable in every client:

• Desktop/Web: a clickable Undo compaction action on or next to the completed compaction marker.
• TUI: a named command-palette/slash-command or keybinding action; where mouse actions are available, the same action should be clickable at the compaction marker.

All entry points must target the compaction boundary itself, not silently fall back to the preceding user message.

Actual behavior

The nearest undo target can be the preceding user message. Undoing from there discards the assistant messages between that user message and the compaction point, so the pre-compaction state cannot be restored exactly.

OpenCode version

1.18.15

Operating System

Linux (WSL2) & Windows 11

Terminal

windows terminal / wezterm