Redo (Ctrl+r) may not restore an undone change

[oribarilan]

Summary

Manual e2e testing of the modular-engine work (#62) suggests redo via Ctrl+r doesn't reliably bring back an undone change. Filing to investigate later. Not a blocker for #62 — that's a pure refactor and redo behavior is unchanged from before.

Observed

Make an edit in the prompt, press u to undo, then Ctrl+r to redo — the change does not come back. Needs confirmation across edit types (simple host edits vs snapshot-restored ones).

Likely cause: undo/redo asymmetry

Ctrl+r dispatches the host input.redo command (src/vim/normal.ts), but our undo is asymmetric:

• u for range/counted deletes (de, dG, 2dd, ...) restores from a plugin-side snapshot via editBuffer.setText (see the undo-snapshot notes in AGENTS.md and the saveUndoSnapshot / undo actions in src/index.ts).
• There is no snapshot-based redo. Ctrl+r only ever calls host input.redo, which has no knowledge of the snapshot we restored.

So a change undone through the plugin snapshot can't be redone. It's also possible the host input.redo command itself doesn't behave as expected for plain edits — worth confirming the command exists and works.

Repro

1. just dev
2. Insert mode: type hello world
3. Escape, then dw
4. u — the word returns (snapshot restore)
5. Ctrl+r — expected: word deleted again; actual: nothing happens

Acceptance criteria

• Confirm whether host input.redo works for simple edits vs snapshot-restored ones.
• Decide: implement a snapshot-based redo stack mirroring u, or document redo as host-only with its limits.
• Add coverage: a unit test for the redo action and an integration test mirroring the existing undo-snapshot test.

Found during manual e2e of #62.