[user-github-me]

If a timeline undo receipt refers to a removed target or backup, the command exits 1 with a raw filesystem error instead of its normal refusal payload. A missing index.html also trips project discovery before the receipt is checked. This follows the nonblocking review feedback in #5279.

Catch missing-file errors while preparing the entire undo batch and return exit 2 with {ok: false, reason, fix} on stderr in JSON mode. Include the missing project-relative path and a recovery hint. Resolve undo projects without requiring index.html so a missing root target receives the same refusal. Preparation still completes before mutations begin.

Validation: six new single/batch cases fail on unchanged main, then all 109 timeline tests and seven atomic-write tests pass. Eight controls through the rebuilt CLI on Node 22 verify JSON and text refusals, unchanged source and backup bytes, and successful batch undo/redo. Workspace and CLI builds, CLI typecheck, repository lint, formatting, test reachability, comment checks and normal pre-commit hooks pass. The overlapping test patch in #5315 still applies cleanly.

Related: #5279.

[jrusso1020]

Verified against the full runUndo and applyFileMutations. Moving the readFileSync calls for target and backup inside the try means any missing file in the batch fails before applyFileMutations writes anything, so the refusal really does leave sources and backups untouched, and the e2e cases assert those exact bytes. An ENOENT raised later inside applyFileMutations (a race on statSync during the atomic replace) is also mapped to the refusal, but that path rolls back the earlier writes first, and a failed rollback surfaces as an AggregateError without code, which still rethrows. So the 'nothing changed' reading holds. requireIndex: false is safe here because runUndo never reads project.indexPath. The PR merges cleanly over #5867 on main.

— Rames