feat: add conflict-safe review revert

[oratis]

Summary

• tag file and Git snapshots with their canonical app-server turn id and record whether a pre-image existed
• add review/revert for completed Apply actions and persist the revert/action/turn relationship
• expose only the internal RestoreReviewAction tool to revert turns; unadvertised Edit, Write, Bash, plugin, MCP, and sub-agent tools are rejected by a host-owned turn ceiling
• perform an all-files compare-and-swap against exact Apply post-images before restoring any pre-image
• refuse subsequent user changes, Bash-only mutations, incomplete legacy snapshots, corrupted or escaped blobs, symlinks, non-files, hard links, and bounded-resource violations
• preserve the normal permission, approval, hook, cancellation, and snapshot paths; restore turns snapshot themselves and can safely delete files created by Apply
• expose conflict-safe revert through VS Code, Desktop, and LSP

Validation

• pnpm format:check
• pnpm lint (one pre-existing warning)
• pnpm typecheck
• pnpm test (1040 passed, 12 skipped)
• pnpm docs:check
• pnpm build
• pnpm --filter @deepcode/desktop test:e2e (4 passed)
• sidecar and VS Code child CJS syntax checks
• VSIX: 8 files, 180.67 KB

[oratis]

Review: approved ✅ — I read restore-review-action.ts line by line; the refusals are the feature

Revert is the most dangerous operation in this stack: it writes over files a user may have edited since. This implementation refuses in every case where it cannot prove safety, which is the only defensible default.

Verified in packages/core/src/tools/restore-review-action.ts

• All-files compare-and-swap against exact Apply post-images before restoring anything. The CAS covers the whole set before the first write, so a partially-modified set aborts before touching disk rather than half-reverting. That's the correct granularity.
• Rollback on partial failure: the restored[] accumulator rewrites currentBytes via Promise.allSettled if any restore throws mid-loop. So an mid-way EACCES doesn't leave the tree in a mixed state.
• Git-kind snapshots are refused outright — 'the action used Bash; an exact file-level revert is unavailable'. Honest: Bash side effects aren't captured by file snapshots, so a "successful" revert there would be a lie. Refusing beats pretending.
• action_turn_id is regex-constrained (/^[a-zA-Z0-9._-]{1,200}$/) before it reaches the filesystem.
• Bounds are explicit and sane: MAX_RESTORE_FILES = 100, MAX_RESTORE_FILE_BYTES = 16 MiB, MAX_RESTORE_TOTAL_BYTES = 64 MiB.
• Restore turns snapshot themselves first (pre-RestoreReviewAction), so a revert is itself revertible. Post-restore snapshot failures degrade to snapshotWarnings instead of failing the completed restore — right priority: the files are already correct, don't fail the operation over bookkeeping.
• Incomplete legacy snapshot pairs, corrupted/escaped blobs, symlinks, non-files, and hard links are all rejected.

The turn-ceiling design is the standout. Revert turns advertise only RestoreReviewAction; Edit, Write, Bash, plugin, MCP, and sub-agent tools are rejected by a host-owned ceiling. Host-owned matters — if the ceiling were client-supplied, "revert" would be a way to request a turn with an arbitrary toolset. As built, a revert turn cannot do anything except revert.

Minor, non-blocking: the rollback path restores content but not file mode/mtime. Fine for the intended use, worth knowing if executable-bit changes ever enter scope.

Validation: CI green; full suite green locally at the stack tip.