Changes touching this path

• the first-push deposit cost this ticket asked about is measured on a copy of this repo tree and recorded in ADR 0057: 1,690 files as one change, a release loot pushing to a release loot-forge --dev under LOOT_NET_TIMING=1, three first pushes to each forge. to a forge without grant_batch the push took 25.1, 38.9 and 27.3 s, and its 1,690 /grant requests took 0.82 to 0.86 s of it, the rest being client work between the requests, which the batched pushes, sealing the same grants in under a second, show is the per-call record and persist rather than the seal; to a forge with grant_batch it took 0.68, 0.81 and 0.94 s over 2 /grants/deposit requests. runner add over the same keys as key-only grants took 0.36, 0.35 and 0.60 s and carried 0.46 MB where the batched deposits carried 8.37 MB. the batching half is lwsrylrv, already landed and live on the forge since v0.4.25-deploy.8, which answers grant_batch true. whether a standing self-grant should be key-only is left to the operator: a second machine that ran loot pull already held every object before loot pull-grants, but the grant body is a copy of the ciphertext in the grant_inbox row that a burn delete leaves and that would outlive a lost blob tier. docs only, no code and no pin, so no mutation; cargo test green, 4863 passed over 144 test result lines with 15 ignored. owes no deploy of its own. it resolves zztslnvz and files qusqlqwm, the burn job leaving the ciphertext of a burned object in grant_inbox (zztslnvz) aeec0058 · 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.