feat: add undo functionality to revert the last turn and restore file changes

- Implemented `/undo` command to revert the most recent completed turn, restoring all modified files and rewinding message history.
- Introduced `FileMutation` type to capture file changes for undo operations.
- Enhanced session management to track and manage undo stack with a maximum of 20 turns.
- Updated command parsing to include user-defined commands from `.shiro/commands.md`, allowing for custom command definitions and substitutions.
- Added documentation for the new `/undo` command and user commands feature.
- Implemented tests for undo functionality and user command parsing to ensure reliability.

docs/undo.md

@@ -0,0 +1,30 @@
+# Undo
+
+`/undo` reverts the most recent completed turn: it restores every file that turn
+changed and rewinds the message history to the point before the turn began. It
+can step back through up to 20 turns.
+
+## How it works
+
+Before a file-mutating tool (`write_file`, `edit_file`, `multi_edit`,
+`apply_patch`) writes, it captures the current bytes of every file it is about
+to touch. That snapshot is stored against the in-flight turn. When the turn
+finishes (having changed at least one file and added at least one message), the
+snapshots are pushed onto an undo log.
+
+`/undo` pops the log and restores:
+
+- a file that was edited — back to its prior contents;
+- a file that was created — deleted;
+- a file that was deleted — recreated with its prior contents;
+- a move — the source restored and the moved copy removed.
+
+Then it truncates the message history to the length it had when that turn
+started, so the model no longer sees the reverted decisions.
+
+## The honest limit
+
+A `bash` command's effects cannot be snapshotted — a network call, a build
+artifact, or a `git push` are not reversible by restoring file bytes. So `/undo`
+covers file-tool edits (including `apply_patch` moves/deletes) and says so; it
+does not pretend to reverse commands you ran via `bash`.