Bug: `lore revision restore` fails with "Dirty node remain after nodes were committed" whenever the delta is pure deletions

[Segurad27]

Environment

• Lore v0.8.4 (CLI + loreserver), Windows 11
• Local server over lore://127.0.0.1, single user, single branch
• File type does not matter (fails identically with .uasset and plain .txt)

Summary

lore revision restore fails deterministically when the target revision's
tree is the head tree minus files (delta = pure deletions). The same
command succeeds when the delta adds files.

Fragmenting files and updating tree hashes
[Error] rehashing state: Dirty node remain after nodes were committed
  at lore-revision\src\commit.rs:176:1
  at lore-revision\src\revision\restore.rs:446 - rehashing state

No revision is created; local is left at the synced-back revision, remote at
head. Recoverable — see workaround.

Minimal repro

echo test > file.txt
lore dirty file.txt && lore stage . && lore commit "add file"    && lore push   # rev N   (file exists)
rm file.txt
lore dirty file.txt && lore stage . && lore commit "delete file" && lore push   # rev N+1 (file deleted)

lore sync <rev N signature>        # brings the file back
lore revision restore "restore N"  # SUCCEEDS (delta = +1 file) -> rev N+2

lore sync <rev N+1 signature>      # removes the file
lore revision restore "restore"    # FAILS (delta = -1 file):
                                   # "Dirty node remain after nodes were committed"

Expected

revision restore records the synced-back state as a new head revision
regardless of delta direction.

Actual

• Addition-delta restores: 2/2 succeeded (including one resurrecting ~147 files).
• Pure-deletion restores: 0/4 succeeded (1-, 3-, 4-, and 5-file deltas).

Ruled out (A/B tested)

• External file handles: identical failure with the Unreal editor open and fully closed.
• File type: identical with .uasset and .txt.
• Stale dirty state: identical after clearing every dirty mark (0 in lore status).
• Residue from a prior failed attempt: reproduces on a fresh sync + restore cycle.
• -f and retrying: no effect.
• The sync itself is clean each time: lore status --scan shows zero tracked
  differences vs. the target revision before revision restore is invoked.

Workaround

Stay at head, delete the unwanted files on disk, then
lore stage --scan <paths> + commit + push. Produces the same tree as the
target revision (5/5 in our use); loses only the automatic Restored:
provenance line.