Changes touching this path

• a push deposits its keys at a forge many to a request: the forge mounts POST /grants/deposit on both grant lane mounts, taking up to loot_net::forge::MAX_GRANT_BATCH grants each as /grant takes one, parsing every blob before filing any, and says grant_batch on /info; Workspace::deposit seals each grant with the new DagRepo::seal_grant, which records nothing, delivers them in calls of at most that count and at most BYTES_PER_BATCH unless one grant alone is larger, and records and persists a call manifest and ledger rows only once the call is answered, so a failed call records none of its deposits and every earlier call stays recorded; a host whose /info does not say grant_batch, a relay or a forge deployed before this, is sent one deposit a request on /grant as before. measured against an in-process forge behind a proxy holding each request 20 ms, a push owing 60 standing self-grants sent 60 /grant requests in 2.73 s to a forge without the flag and 1 /grants/deposit request in 0.68 s to one with it. the narrower lock for the land sync is not built: outside the harbor the no-arg primary adopt would catch up to a main another land has projected but not yet published or format-checked (#1776), and the ADR 0098 race fold writes landed main from a position a later land may have passed, both needing a design decision. ADR 0057 and CONTEXT.md say so, and the ADR 0057 sentence that only seal_and_deliver_grant writes the ledger is corrected. red under named mutations, each restored: one deposit a call at a batching forge (0 passed and 1 failed), the forge filing each blob as it parses (0 and 1), no byte bound (0 and 1), recording a call before delivering it (0 and 1), the /info flag unread (0 and 1). cargo test green, 4815 passed over 144 test result lines with 14 ignored, and the site gate green at 889 passed. owes a forge deploy, and the primary release binaries a rebuild for a land to batch its deposits; it also carries a comment on ywuxnuxp; it also files yznnvzks, the lock half parked on a naming and a format decision (lwsrylrv) 772e1f9d · 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.