Changes touching this path

• loot seek --gc exits 1 when a removal it decided failed, with every row and the H row still written and the error still on stderr: gc::Report now implements Emit::exit_code (#1764), 1 when any decision carries failed and 0 otherwise, 1 being the ADR 0025 row for an I/O error and the code the error path in main.rs exits with, the reasoning gates::EXIT_UNRUNNABLE records; the cap after a refresh is unchanged and a failed removal there does not move the question exit. the ticket named the hook #2127, which is loot pipeline, the verb whose code it cites; the hook is #1764. the ADR 0023 #2125 amendment gains the exit sentence, the ADR 0090 #2125 amendment says the invocation exits 1, and the seek module doc scopes its refusal-only exit rule to a question. pinned in a_failed_removal_is_reported_as_failed_and_stops_nothing: the report exits 1, and 0 with the failure cleared. red first against the unchanged code (0 passed and 1 failed). red under mutation, counts read each time: the code fixed at 0 (0 and 1), fixed at 1 (0 and 1), keyed on a decided removal rather than a failed one (0 and 1), each restored to green. through the binary under a scratch LOOT_SEEK_CACHE with one position held open, the lane binary exits 1 and the primary release binary 0, both printing the removed and failed rows. no migration, no format byte and no published wording moves, so this owes no deploy. the workspace suite is green (4325 passed, 0 failed, 12 ignored) (#2154) 1dc9e314 · 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.