Hot-exit does not persist redo/undone state (futureStack) — undo of a saved edit is lost on reopen

[zknpr]

Split out from PR #424 review (CodeRabbit, src/core/undo-history.ts:258) as a tracked follow-up. Pre-existing on main — not introduced by the web-edit PR — and affects both desktop and web, so it's out of scope for #424 and deserves its own change.

Problem

ModificationTracker.serialize() persists only { timeline, checkpointIndex }:

// src/core/undo-history.ts
serialize(): Uint8Array {
  const payload = { timeline: this.timeline, checkpointIndex: this.checkpointIndex };
  ...
}

But stepBack() (undo) and rollbackToCheckpoint() move entries into futureStack (the redo stack), which is not serialized. Hot-exit restore opens the last saved DB bytes and replays only getUncommittedEntries() (timeline.slice(checkpointIndex)).

Consequence

Repro:

1. Make an edit, save (checkpoint advances past the edit).
2. Undo that saved edit (entry moves to futureStack; document is now dirty).
3. Hot-exit (close VS Code with the dirty doc), then reopen from the backup.

Expected: the database reflects the undone state (edit removed).
Actual: restore opens the saved bytes (which still contain the edit) and replays no forward entries, so the undone state is lost — and the redo stack is gone entirely.

Possible approaches (design decision — not prescribing)

• Persist futureStack + futureStackSizes and reconstruct the cursor on restore, then replay the net state (requires representing the undo, e.g. applying inverse ops or re-deriving live state).
• Snapshot the live DB bytes for the hot-exit backup instead of replaying forward entries from the saved image (exact, simpler to reason about, larger backups).

CodeRabbit tagged this a "Heavy lift"; flagging for a dedicated PR with its own tests (desktop + web hot-exit round-trips covering undo-of-saved-edit).

Refs: PR #424 review thread on src/core/undo-history.ts.

[zknpr]

Scope: also covers concurrent-key-safe undo of json_patch cell edits

Attempted in #426 and pulled (see that PR for the full analysis + 14 edge-case tests on branch fix/json-patch-undo). Both belong here — they're undo/redo history-fidelity problems that need a non-lossy representation:

1. Redo/futureStack persistence across hot-exit (original scope of this issue).
2. Undo of a json_patch cell edit — value-replacement undo (current 1.5.0 behavior) restores the whole captured document, clobbering a concurrent change to a different key of the same cell. The merge-patch inverse approach attempted in fix(undo): operation-aware json_patch undo — preserve concurrent keys (1.5.1) #426 is architecturally lossy (RFC 7396 can't express set-null vs delete, delete vs empty-object, or preserve concurrent siblings without reading the current value) — 8 edge cases across 3 review rounds.

Recommended approach (read-modify-write), reusable for both: at undo time read the current cell value; if it's a JSON object, restore only the keys the forward patch touched — prior value restored exactly (incl. explicit nulls), keys the edit added deleted, recursing for nested objects — then write the full result back. Fall back to value-replacement when the current value isn't a JSON object. This is non-lossy, handles all 8 #426 edge cases, and keeps batch atomicity (results are plain set updates, so updateCellBatch's SAVEPOINT still applies).

The 14 edge-case tests from #426 (tests/unit/json_utils.test.ts, sqlite_db.test.ts, nativeWorker.test.ts on that branch) encode all the cases the implementation must satisfy — reuse them.