F2: continue a task after a scope pause (reconcile the prefix, validate the rest)

[mchwang]

Follow-up to #68 (F2b). After an item changes files outside its plan item, the task pauses in needs amendment with a checkpoint. plan-format.md ("After each run") says what happens next: "After a person approves a revised plan and continuation, reconcile the executed prefix with the audited current head and validate remaining operations from that actual checkpoint; never silently authorize the extra file or erase its original scope finding."

#68 does not build this. Once a task has a scope checkpoint, ItemExecutor.runTask refuses to run any further items; it fails closed. Reviews of #68 showed that a partial continuation gate goes wrong in several ways, which this slice must design for:

1. An approval becomes unusable once later work has used it up.
   • Approval is bound to one revision and one snapshot (approveContinuation requires the current snapshot to equal the checkpoint's).
   • After a continued item commits, a new snapshot exists. If the plan is then revised again, the old approval no longer matches, and a new approval is refused.
   • Needed: decide when a checkpoint counts as consumed.
2. The continued items must be validated from the checkpoint.
   • fromItem must be the next item after the checkpoint's executed prefix, and its depends_on items must be done.
   • Otherwise a later item can run without the ones it depends on.
3. The first continued item must start from the audited head.
   • The continued run must reconcile the current snapshot with the checkpoint's snapshot, not with whatever head was observed since.
   • This overlaps F2b: connect the real workspace (partial export, failed-run audit, durable safety findings, commit export) #87 item 5, the HEAD observation.
4. The checkpoint must record the audited actual tree.
   • Today Checkpoint.baseEntries records the plan's base tree from planContext. The store type calls it "Runner-audited actual tree".
   • The actual tree at the item's commit includes earlier items' adds and renames and the out-of-scope files.
   • Nothing reads this field yet. Continuation will need the real tree, probably from D (D: inspect task changes and make runner commits (needed by F2) #66, F2b: connect the real workspace (partial export, failed-run audit, durable safety findings, commit export) #87).
5. Re-running completed items.
   • A run without fromItem, after items completed in an earlier run, re-runs them on top of their own commits.
   • Needed: decide how a run finds its starting point.

🤖 Generated with Claude Code

[mchwang]

From the round-6 review of #68: runTask trusts fromItem on any task, not only after a pause. On a fresh task, runTask({ fromItem: 'P2' }) runs P2 without P1, although P2 depends_on P1. A scope pause in that run then records P1 in the checkpoint's completedItems, although it never ran. The run's starting point (item 5 here) should validate that every item before fromItem completed at the current head, and completedItems should list only items that actually ran.

[mchwang]

From the round-23 review of #68: a run that stops because the runner's only writable slot is taken by another task (No free runner slot) leaves the task running with no attempt. A plain re-run then starts again at P1, re-running items that already committed. The run's starting point (item 5) should handle this as well: continue from the first item without a completed attempt at the current head.