feat: /rewind should optionally restore edited files (OpenCode-style file revert), disk-backed to keep RAM flat

Summary

/rewind N currently rewinds only the conversation transcript, not the files the agent edited. OpenCode's rewind restores both the chat and the working-tree files to the state at that point. This is a request to add opt-in, disk-backed file restore to jcode's rewind so users can truly "go back" after the agent makes edits they don't want.

Current behavior (confirmed in source)

• Agent::rewind_to_message() in crates/jcode-app-core/src/agent/turn_execution.rs snapshots only self.session.messages, truncates them, and persists. No file state is captured or restored.
• RewindUndoSnapshot (crates/jcode-app-core/src/agent.rs) stores only messages, provider session ids, and visible_message_count.
• In-app help confirms it: "/rewind N — Rewind to message N (drops everything after it and resets provider session)."
• No slash command (/fix, /fork, /transfer, /clear, /compact, /git) restores files. Enumerated all of commands.rs.

So after the agent writes/edits files, /rewind rolls back the chat but leaves the code changes on disk. Users coming from OpenCode/Claude Code expect the files to revert too.

Is this intentional?

It appears to be a deliberate architectural stance, not an oversight — the README (the "new git-like primitive" note) and docs/AGENT_NATIVE_VCS_CORE_BEHAVIOR.md describe a planned agent-native VCS where every edit is a "revertible and replayable" draft patch. This issue asks whether that longer-term VCS is the intended home for file-revert, or whether a lightweight file-restore on /rewind is acceptable in the interim. Many users just want OpenCode parity today.

Proposed design (lightweight, disk-backed)

1. Snapshot on write. Before any edit tool (tool/write.rs, tool/edit.rs, tool/multiedit.rs, tool/apply_patch.rs, tool/patch.rs) mutates a file, save the prior bytes to a content-addressed store under ~/.jcode/sessions/<id>/snapshots/, indexed by message/turn. New files are recorded as "did not exist."
2. Restore on rewind. Extend rewind_to_message(N) to also restore every touched file to its state as of message N; extend undo_rewind() symmetrically.
3. Surface. Either make /rewind N restore files by default (OpenCode parity) or add a distinct /revert N / /rewind N --files so conversation-only rewind stays available. Behind a config flag (e.g. [rewind] restore_files = true) so it's opt-in and non-surprising.

RAM / performance

This should not increase steady-state RAM meaningfully, keeping jcode's low-RAM promise:

• Prior file bytes are written to disk, not held in memory (same approach as OpenCode's on-disk shadow snapshots).
• Only a small in-memory index (message N → file hash pointers) is needed.
• The cost is disk space (bounded/prunable per session), not RAM.

Acceptance criteria

• With the feature enabled, /rewind N restores edited files to their message-N state, and reports which files changed.
• /rewind undo restores files forward again.
• New-file creations are undone (file removed) on rewind, and re-created on undo.
• Feature is opt-in via config; default preserves today's conversation-only behavior until decided otherwise.
• No measurable steady-state RAM regression (snapshots are disk-backed).
• Works for all edit tools: write, edit, multiedit, apply_patch, patch.

Environment

• jcode v0.54.4
• Linux x86_64

Start with Agent::rewind_to_message in crates/jcode-app-core/src/agent/turn_execution.rs and RewindUndoSnapshot in crates/jcode-app-core/src/agent.rs, then inspect the edit tools named in the issue. Trace how /rewind and undo currently persist and restore session state before deciding how disk-backed snapshots and configuration should fit. Done means the chosen design covers all listed tools, new files, undo, reporting, and the RAM constraint with tests.