Changes touching this path

• loot apply-patch no longer deletes a file its deletion stanza does not describe: the deletion arm now checks its preimage, so the lines the stanza removes, with its no-newline marker, must equal the file on disk in the patch line space or the whole run is refused naming the path and why, a stanza with no hunks deletes only an empty file, and --check gives the same refusal. the binary test is now the exporters own delta::is_binary, so a NUL-bearing file is refused as binary too. spawned-binary tests went red before the change (1 passed, 4 failed), with the preimage check removed (2 passed, 3 failed), with the old utf8-only binary test (4 passed, 1 failed), with a hunkless deletion always applied (4 passed, 1 failed) and with the trailing newline ignored (4 passed, 1 failed), and the format-patch round trips of a text file, a file with no trailing newline and an empty file stay green. the comparison is in the line space, so the #1807 CRLF deletion still applies; its fixture now holds the lines its stanza deletes, which it did not, and comparing with the carriage returns kept turned that pin red (11 passed, 1 failed). ADR 0082 section 2, the #1809 and #1993 comments and CONTEXT.md state the preimage rule, and the workspace suite is green (#1992) 98894a0a · 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.