Changes touching this path

• loot apply-patch closes the preimage gaps #1992 and #1995 left: an add is refused over a path holding bytes other than the ones it adds, which it used to write in front of them, a modify stanza with no hunks is refused, which wrote an empty file at an absent path, a deletion of an absent path is refused rather than reported as done, and a patch that writes or deletes one path in more than one stanza or renames one old path twice is refused. the similarity index, dissimilarity index and index rows are read past, so a git format-patch -M rename applies as a rename where it used to write an empty file at the new path, and another unread row above hunks is refused by name. apply_strict now reads a deleted last line without the no-newline marker as a claim that the file ends with a newline, the deletion arm compares through apply_strict, and the writer no longer discards a removal error. ten new spawned-binary tests went red before the change (deletion 5 passed, 2 failed; preimage 0 passed, 4 failed; rename 8 passed, 4 failed), a new pin for a deleted file that grew a line holds the unified deletion check, and over the apply-patch and format-patch test files the pins went red with the add check removed (46 passed, 2 failed), the hunkless modify refusal removed (47 passed, 1 failed), the git rows unread (47 passed, 1 failed), the unread-row refusal removed (46 passed, 2 failed), an absent deletion planned as a delete (47 passed, 1 failed), the shared path check removed (47 passed, 1 failed), the shared rename source check removed (47 passed, 1 failed), the newline claim removed (46 passed, 2 failed) and leftover lines ignored by the deletion check (47 passed, 1 failed). the format-patch round trips stay green, ADR 0082 gains section 4, one table of what each stanza class checks, its rename paragraph no longer claims more than the hunks compare, CONTEXT.md states the rules, and the workspace suite is green (#1997) 15e2d13e · dbf3dbe6…
• a modify stanza needs a preimage here, and a patch carries the ending of the line it shows: #2005 read a modify aimed at a path absent here as an empty file, so hunks that applied to nothing wrote a new file with not a line checked and hunks that did not reached the three-way against a base this tree never held, which format-patch never writes and git apply refuses by name, so the modify arm refuses naming the path and --check answers the same, both being one plan. the trailing newline is one cause seen from two ends: str::lines is not injective, so the seam gives the two sides a last line they can share while their endings differ, and the marker is a claim about one side, so a shared last line came out as context with nothing under it and the file was rebuilt with whatever ending the applier already had. format-patch now renders over a line space where an unterminated side carries the fact on its last line, render::patch_line_space, which is the git token of a line and its terminator, and takes the alignment again there, the same matcher on a different token and never a second differ, paid only where a side is unterminated; a last line whose ending changed then leaves as a removal and an addition, which is what git writes, and an ending that moved far from every other change gets a hunk at the end of the file. apply-patch reads an unmarked old-side last line as a claim of a trailing newline on a kept line as on a removed one, and takes the ending of the result from the last line it wrote, kept or inserted alike. a change with no line-level difference stays withheld, and its omitted row now carries the reason and the remedy: this body quotes exactly the rows the seam counted as disclosed, so minting a hunk for a row it counted as summarized is that safety claim coming apart, and emitting it means moving the seam and diff --content with it, which is the wider change to make if it is reopened. ADR 0082 section 3 records both decisions, section 4 states the rule the modify row now enforces, and CONTEXT.md says where the ending rides. red under mutation, counts read each time: the absent-path refusal removed (apply_patch_preimage 4 passed and 1 failed), the re-alignment dropped so the seam hunks are rendered over the marked lines (patch_trailing_newline 2 passed and 1 failed, the older marker pin still green at format_patch 12 passed), the mark itself removed (format_patch 11 passed and 1 failed), the ending check narrowed back to a removed line (2 passed and 1 failed), the kept line deciding the ending only when marked (2 passed and 1 failed, and uncaught at 3 passed and 0 failed until the shape whose result ends on a kept line was added), and the omitted row put back to its old words (2 passed and 1 failed). no migration and no store or wire byte moves, and the patch grammar is untouched with no row added or removed, so PATCH_FORMAT holds and this owes no deploy. the workspace suite is green (4066 passed over 130 binaries, 8 ignored) (#2005) 535e1674 · dbf3dbe6…diff

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.