Changes touching this path

• a save no longer fails when the rename that finishes a loose object is refused over an address another writer already landed. persist_codec::save_objects_loose probes for the address before it stages, a writer of the same address can land it between that probe and the rename, and the rename is then a replace, which a reader holding the landed copy without FILE_SHARE_DELETE refuses as os error 5 for as long as it holds, past the retry budget. finish_stage now answers a refused rename with the address on disk by dropping the stage, since the name is the content address, and still propagates a refusal with the address absent. this is the second sighting on this ticket, concurrent_stage_of_same_address_does_not_tear red on Access is denied (os error 5): a hold on the destination refuses a rename as 5 and a hold on the stage as 32, and with a reader holding the landed address and a sleep both added temporarily that test went red at the same unwrap with the same message in 8 of 10 runs, and green in 10 of 10 with the fix. who held it in the sighting is not established, since a stripped copy of the race counting every refusal drew none idle or with the CPU saturated. the first sighting, a_scanner_holding_the_staging_file_does_not_fail_a_save red on os error 32, is not reproduced and this does not claim it: under a saturating load a 120 ms sleep, the length of the scanner hold, woke within about 206 ms while the retry budget stretched to about 1.5 s. red under mutation, counts read each time: the fallback disabled (0 passed and 1 failed), the stage left behind (0 and 1), every refusal swallowed (0 and 1), restored to 1 passed. no migration and no format byte moves, so this owes no deploy. the workspace suite is green (4263 passed over 136 binaries, 10 ignored) (#2233) 4470683c · 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.