Changes touching this path

• loot resolve on the untracked home position now writes the resolved path to disk, and only that path, through the one-path settle a tip-tracking position already used, so the next capture no longer reads the pre-resolution bytes as an edit and loot new no longer signs a change that reverts the resolution. measured first in scratch repos on the home position, on a primary with a pinned tip and in a spawned lane: only the home position left the tree untouched, and on all three a re-run of the stopped revert over a tree showing the resolution still stops on the same path with the resolution as ours, because change_delta_merge runs its three-way without the settled ledger on purpose (#744). so --continue still closes rather than replays, ADR 0080 gains a #1798 amendment giving that reason, the resume module doc no longer names the tip-tracking arm as the one that skipped the write, and CONTEXT.md gives the reason too and names the stopping verbs by STOPPING rather than by a list that lacked apply-patch and move. the two new tests went red on the unchanged code (0 passed, 2 failed), the home-position test went red at its loot cat assertion with the disk assertion removed and at its sibling-edit assertion with the write widened to a whole-tree materialize (0 passed, 1 failed each), and the replay pin went red with the full ledger handed to the three-way (11 passed, 1 failed). the workspace suite is green (#1798) 31ffdf95 · dbf3dbe6…

Renames are not followed. loot's tree maps a path to an address, so a rename is a delete and an add. This list is the history of the name, not of the bytes.