Changes touching this path

• loot pull-grants asks a forge from a cursor, where it fetched and filed the whole mailbox on every run: the cursor the forge issues with each answer is kept in .loot/grant-cursors per canonical remote and mailbox key beside the keyring, read by the grant collection and by no open and no save, written after the keys are saved and never past a grant left pending, and a cursor the forge refuses as a bad request is asked again from the origin once; a relay, and the first run, pull the whole mailbox as before. the apply says whether it filed a key, so a pull counts the grants already held and prints the surface hint only when it filed one. on a copy of the desktop store against the live forge a whole pull of 8,612 standing self-grants took 102 s before and 96 s after, and the pull after it 0.33 s with a 21 byte answer. the 142 s the ticket put on the re-apply was the 52 MB answer arriving, 132 s timed inside the verb against 0.68 s for the loop that unwraps and files the grants, so skipping held keys was not built. red under named mutations, each restored: the kept cursor never sent (3 failed and 1 passed), no fallback on a refused cursor (1 and 3), a delta answer dropped (2 and 2), the cursor moved past a pending grant (1 and 3), held grants not counted (1 and 3), the surface hint unconditional (1 and 3), and a save that reads the cursor file (1 and 0). cargo test green, 4907 passed over 145 test result lines with 15 ignored. CONTEXT.md and ADR 0057 say so (wvyrkooo) 1d53db98 · dbf3dbe6…
• loot pull-grants keeps the cursor it asked from when the ack of the grants it filed fails, where it moved past them, so the forge kept them un-acked while this store never fetched them again, and stderr now says the next pull fetches them again to ack them. which grants hold the cursor is read off the refusal type: an envelope or frame of a newer version than this build reads, a quarantine write that failed, and an apply refusal that never_applies does not name hold it, while an envelope or frame that does not read, a frame that is not a sealed grant, an expired grant and a key not sealed to this identity are named on stderr as grants that can never apply here and no longer hold it, where one such grant in the first answer kept every pull a whole pull. a failed unseal carries the unauthorized code. the wvyrkooo pin of a grant left pending used a key not sealed here, so it now pins that such a grant is passed, and the hold is pinned by a failed quarantine that the next pull quarantines and by a newer frame and envelope. the forge cursor carries no instance identity and the forge has none to give it, so CONTEXT.md, ADR 0057 and grant_cursors say that any forge whose deposit orders start again below a kept cursor, restored or a new instance behind the same URL, misses the same way until .loot/grant-cursors is deleted. red under named mutations, each restored, each 1 failed and 0 passed: the failed ack ignored, the old ack wording, an expired grant held, a key not sealed here held, the unseal left a backend error, a bad envelope held, an unreadable frame held, a failed quarantine passed, a newer frame passed, and a newer envelope passed. cargo test green, 4919 passed over 144 test result lines with 15 ignored. owes no forge deploy (lxmysqxp) 71d7905c · dbf3dbe6…diff
• loot pull-grants now keeps the forge cursor only when every grant of the answer was handled, kept as standing custody or found never to apply, where each skip branch had to count its grant to hold it, so a grant no branch counts holds the cursor; a frame of this build format whose tag this build does not know, named by Frame::newer_tag over the Tag the decode dispatches on, holds it as a newer format does, where it passed as never applying; a grant expired by less than EXPIRY_GRACE_SECS, a day, longer than the widest time zone offset, is left pending in case this clock runs fast; and a failed unseal is named on stderr as a key not sealed to this identity, as the docs say. the ferry remedy matches every DeltaClass, its split test literal is joined, it says not to seal while loot status shows a deletion, and the seal-WIP refusal of a bare loot adopt or loot ferry counts the deletions the override would sign, read from two trees and only when it refuses. red under named mutations, each restored, failed and passed: the cursor moved regardless (5 and 8), a never branch not counting (4 and 9), an unknown tag passed (1 and 12), newer_tag at any major (1 and 0), no grace (1 and 12), an expiry always held (1 and 12), the old unseal wording (1 and 12), no deletion count (1 and 6), a count on every refusal (1 and 6), the old remedy ending (4 and 3), and a DeltaClass arm dropped fails to compile. cargo test green, 4923 passed over 145 test result lines with 15 ignored. CONTEXT.md and ADR 0057 say so. owes no deploy (uuqwrkyt) 5a473dfe · dbf3dbe6…diff

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.