Changes touching this path

• loot apply-patch no longer empties a renamed file: a rename stanza now reads its preimage from its old path, so a pure rename moves the old bytes unchanged and a rename with hunks applies them strictly to the old content, the whole run is refused naming the path when the old path is absent, binary or not the content the hunks were made against, or when the new path already holds other bytes, --check gives the same refusal, and the old path is removed only after every new path is written and not when another stanza of the patch writes it. a git copy row is refused by name, since format-patch writes none and it used to write an empty file at the copy path. before the change a pure rename exported by format-patch applied as an empty new file with the original deleted and exit 0, a rename with an edit failed with a garbled error, and the first seven spawned-binary tests went red (0 passed, 7 failed); with the pure rename reading the new path (5 passed, 3 failed), the new-path check removed (7 passed, 1 failed), an absent old path read as empty (7 passed, 1 failed), the old-path binary check removed (7 passed, 1 failed), the hunks ignored (6 passed, 2 failed), the copy refusal removed (7 passed, 1 failed), the old path never removed (5 passed, 3 failed) and the guard for an old path the patch also writes removed (7 passed, 1 failed). the existing format-patch and apply-patch round trips stay green, the split literal in the conflict error is joined, ADR 0082 section 2 and CONTEXT.md state the rename rule, and the workspace suite is green (#1995) cb93ea4d · 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.