Changes touching this path

• the tutorial interrupt handler reports what the removal did instead of that it reached the line, asks again when a concurrent writer takes the first ask, and the interrupt test pins the message against the filesystem rather than the tree alone. arm_signal_cleanup discarded the result of remove_dir_all and then printed the removed line regardless, so that line was a report of reaching that point over a tree that is where the private keys of both demo identities and the decrypted .env live (#513): the count-attempted-vs-done class in operator-facing output, and why Test - landed main went red five times through the 2026-09-16 run with the removed line and exit 130 both passing above the assertion that failed. the CI failure itself is NOT reproduced here and is not claimed to be, since that path is the linux runner, so what is measured on this windows desktop is the mechanism and the decision. a throwaway probe made remove_dir_all fail under a concurrent writer with DirectoryNotEmpty (os error 145), the windows spelling of the ENOTEMPTY the ticket reasons about: one attempt left the tree behind in 33 of 400 rounds at a 50 write burst and in 299 of 300 at 200 writes, three attempts 50ms apart left it behind in 0 of 200 and 0 of 300, and a writer that never stops defeated every attempt count measured, which is why the failure line exists rather than a fallback nobody expects to see and why both constants are the values they are. that table is recorded on SWEEP_ATTEMPTS as a measurement rather than as something re-derivable from the source. sweep_interrupted_tree takes its removal as a parameter because the handler ends in std::process::exit and cannot be called from a test at all, so the arm that reports a failure is reachable there and nowhere else; the failure line names the path, the error and that a later run reaps it, in the register of the note the handler already prints when it cannot arm, and writeln! over println! plus the discarded results after the report are untouched. red first, both ways: the discarded result put back reddens the refusal pin (8 passed, 1 failed, printing the removed line over a tree nothing removed), the attempt count at one reddens the retry pin and the real-writer pin (7 passed, 2 failed, the second naming os error 145 under a live writer, and 10 of 10 red run alone), and through the integration test, the handler removal forced to fail reddens it naming the refusal in the words of the handler (2 passed, 1 failed) while that mutation plus the pre-fix reporting reddens it naming a removal line over a tree still there (2 passed, 1 failed), which is the CI shape reached deliberately on windows. the real-writer pin stops its writer on the first attempt rather than after a fixed burst, because the burst version outlasted the sweep inside a full workspace run and went red, the load-sensitivity of #1693; it therefore does not guard the spacing, which is stated on SWEEP_SPACING and rests on the probe, with the spacing at zero measured green 5 of 5. the pre-interrupt tree.exists vacuity guard stays, and it is what makes the CI reading trustworthy. no migration, and nothing outside the tutorial verb moves, so this owes no deploy. the workspace suite is green over two consecutive runs (3863 passed over 119 binaries, 7 ignored) (#2037) 413891ed · 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.