Changes touching this path

• the relay mailbox takes the door the relay already writes objects through, and the keypair archive reports a held file rather than waiting it out: #2026 routed the object store loose rename through store::rename_retrying and left two sites its census named, and the question here was where that helper should live. it does not move. the mailbox needed no export at all, because store::atomic_write is already public and loot-net has called it for every loose object since storage::write_loose_object was written, so save_index and write_blob now stage through that door and both ends of their renames are waited out, the reader holding the index it replaces and the scanner holding the staging file, and the fixed index.tmp that two concurrent writers shared is gone with it. the wait is spent on the host too, where rename has no sharing window and the refusals that predicate answers to are permanent, and that is accepted rather than gated on cfg(windows): a second spelling of one predicate is the shape #565 is the record of, and the relay has paid this on every loose object all along. loot-identity cannot reach the helper and the helper cannot come to it, since that crate depends on no workspace crate but loot-codec, which is the no-fs wasm core a filesystem retry loop is defined not to live in, so the choice was a second copy or a report. it reports, and on its own terms: a store staging rename waits out a scanner passing over a file microseconds old, where what is held here is a long-lived keypair file whose holder no budget outlasts, and a rotation is one operator-driven act where a refusal costs a re-run. what makes that safe is the order, so id.pub now moves before id and a refusal leaves the private key in the active slot, where archiving id first left a repo whose key had moved and whose re-run met NoKeypair; the refusal names both paths. the census loses its two mailbox rows and its blind-instrument guard stops reading a file that renames today, asserting instead that every crate directory the tree declares is in the walk. red under mutation, counts read each time: the index save put back to a bare rename (loot-net mailbox 20 passed and 1 failed), the blob write put back (20 passed and 1 failed, refused with os error 32 on the source), the archive order restored (loot-identity 3 passed and 1 failed, the private key gone), the paths dropped from the refusal (3 passed and 1 failed), a retry loop given to the archive (3 passed and 1 failed, the rotation waiting the hold out and returning Ok), a bare rename put back where the census cannot see it (store_rename_census 3 passed and 1 failed) and the walk cut to three crates (2 passed and 2 failed). ADR 0016 records the archive decision and store.rs records where the helper stays. no migration, no wire or format byte moves and no schema moves, but the relay binary changes on its own write path, so this owes a relay redeploy. the workspace suite is green (4083 passed over 130 binaries, 8 ignored) (#2112) 8b194a68 · 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.