Changes touching this path

• a save no longer fails because something opened the staging file it was about to rename: persist_codec::save_objects_loose finished a loose object with a bare fs::rename, under a comment in store.rs asserting that this rename creates rather than replaces and so opens no such window, which is true of the destination and silent about the source. a rename takes DELETE on the name it moves, so a scanner holding the staging file refuses it as a reader holding the destination refuses a replace, and that is what #1897 measured as an ordinary save failing with an opaque backend error in 11 of 50 paired rounds and what the suite saw as this crate racing itself. that rename now goes through store::rename_retrying, whose predicate already answered to both spellings the contention takes, error 5 through the permission-denied kind and raw error 32; the kind-versus-raw half of that was resting on a platform fact nobody had asserted, so it is asserted now where the platform can answer it. two pins carry it. a staging file held without FILE_SHARE_DELETE refuses a bare rename with error 32 and does not refuse the retrying one; and a scanner that watches the object directory and opens whatever tmp file turns up does not fail a save, with rounds retried until the handle is confirmed open, so a run that never entered the window fails rather than going green having measured nothing. red first with the counts read: with the bare rename restored the scanner pin fails with backend os error 32 out of save_objects_loose and the census reddens naming save_objects_loose, which no row covers (1 passed and 1 failed in the lib, 1 passed and 1 failed in the census); with the scanner looking for a suffix nothing has it refuses on zero catches over eight rounds rather than passing vacuously (0 passed and 1 failed); and with raw 32 dropped from the predicate the held-staging pin, the scanner pin and the predicate pin all go red (0 passed and 3 failed). the census of the other renames is derived rather than listed: tests/store_rename_census.rs walks every fs::rename under crates/*/src, keys each by its file and the fn it sits in, and asserts the set both ways, so a new rename arrives red until somebody names which end of it can be held and a named one that stops renaming arrives red too; with the relay index rename swapped for a copy the missing row reddens it (1 passed and 1 failed). the relay mailbox and the identity rotation carry the same source window and are named there with why each is out of reach from here rather than fixed. no migration and no wire or format byte moves. the relay links this crate and does reach this path, so its bytes rebuild, but the window is windows sharing contention and the relay runs on linux, where the only thing the predicate answers to there is a permanent permission denial that now waits out its budget before reporting, exactly as atomic_write already does; so this owes no deploy. the workspace suite is green (3985 passed over 124 binaries, 7 ignored) (#2026) e57db04d · 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.