Changes touching this path

• a save writes the grant manifest before the keyring and escrow, where it wrote it after them, so a save of filed grants that wrote the keyring and then failed left each key held with no manifest row, and every retry, loot grants --trust or loot pull-grants, found the key held and by the #503 rule recorded none: the store INVENTORY, the save walk order, now puts the manifest row ahead of the custody it records, and a save that fails between them leaves the row, which the retry files the key under. the #503 rule itself is unchanged, since recording a row for a key already held is what lets a peer name itself grantor of content held here. pinned: a_save_that_fails_after_the_keyring_leaves_the_manifest_row_for_the_retry, with the escrow made unreadable under the save, red before the change (1 failed and 4 passed over the grants tests, 0 rows of 2), and a_trust_whose_save_fails_leaves_every_grant_quarantined now asserts the rows are written and no key is when the keyring is unreadable. red under named mutations, each restored: the old order (2 failed and 3 passed), and the manifest between the keyring and the escrow (1 failed and 4 passed). cargo test green, 4952 passed over 145 test result lines with 15 ignored. CONTEXT.md says so. owes no deploy (rtqpwklo) 9e380a5f · 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.