restoreWorkingTree()

function restoreWorkingTree(
   executor, 
   context, 
   target, 
   options
): Promise<WorkingTreeRestoreResult>;

Defined in: packages/rxdb-plugin-working-tree/src/working-tree/restore-command.ts:396

把目标 commit 的内容作为新的未提交变更写回当前工作树（FR-013）。

Parameters

Parameter	Type	Description
executor	TransactionExecutor	调用方那个写事务的执行器；本函数不自己开事务
context	CommitWriteContext	见 CommitWriteContext：造条目行的实体管理器与 codec 解析上下文
target	WorkingTreeRestoreTarget	见 WorkingTreeRestoreTarget；entities 缺省即整个 commit
options	WorkingTreeCredentials	见 WorkingTreeRestoreOptions；三个捕获位全部必填

Returns

Promise<WorkingTreeRestoreResult>

见 WorkingTreeRestoreResult

Throws

CommitGraphCorruptedError 当前分支的提交图已损坏时（FR-051）

Throws

TypeError 历史行的 patch 列里存的不是普通对象

Remarks

步骤顺序全是有理由的：

1. 先读 active 分支令牌，此后一切都打在它身上。事务中途再查一次并把恢复写过去，等于用户在 A 分支上点的恢复落进了 B 分支的工作树。
2. 损坏守卫先于一切。 反过来的话，一条已损坏的链上、凭据又恰好对得上的恢复会直接落库， 把历史里一段自己都校验不过的内容物化进工作树（FR-051）。
3. 三次比较、dirty 守卫、可达性、判空、兼容性预检，全部先于任何写入。任一不过即返回失败 出口，此时没有任何东西需要回滚——这正是它们做成返回值而非异常的原因（FR-033 的「零变化」 在这里的物理含义就是这个顺序）。
4. CAS、写条目、写会话，全在调用方那一个事务里（见 writeRestore）。

dirty 判据读的是 state.entryCount——与 status().clean 同一个表达式。分头实现的话两者迟早在 某次改动里分岔，而分岔的症状是「界面显示干净，恢复却说脏」，用户没有任何手段能查出差在哪 （FR-014）。

物化结果为空（entities 一个都没命中）与重放路径为空走同一个 no-op 出口：两者要写的东西都是 零，而为一次零写入建一行 active 会话，正是 FR-042 点名的那个死角。