Changes touching this path

• a forge ingest no longer reads the object row of each key its bundle carries one round trip at a time: publish::published_rows reads the rows of the whole key lane in one object_rows call, where a push presents the key of each unembargoed Internal entry of each change it sends, so the lane grows with the tree. measured on a throwaway Postgres 18 with a debug build, a one-change push over a 7,200-path tree spent 1.68 s of its 1.83 s ingest in that loop and now 26 ms, prepare at 60 ms and the store transaction at 84 ms being most of the rest; the #2426 ancestry check read no graph (1.7 ms), and the standing self-grant deposits (zztslnvz) go to /grant after the push, not /ingest. the forge client settles an /ingest whose answer was lost after the request may have reached the forge (any transport failure but a failure to connect, or a 5xx) by asking /ref up to 5 times, a second doubling, as the SDK does (#2486): a tip moved on to the declared head set reads as the push taken, and loot push says the answer was lost and goes on as committed, so a land no longer reports relay=FAILED for a push the forge took; a tip at other heads or still unmoved stays a failure that says what asking found. pinned: a push makes the same store calls over a 16-path tree as over a 160-path one, one object_rows and no object, and three loot-net cases over a stand-in forge. red under named mutations, each restored: a per-key object read (0 passed and 1 failed), a lost answer not settled (0 and 3), a 5xx not settled (2 and 1), heads compared in declared order (2 and 1), and a tip moved anywhere read as taken (2 and 1). cargo test green, 4753 passed over 145 binaries with 13 ignored, and ci/local.sh green, its site live suites at 80 passed. owes a forge deploy, and the client half bites once the primary loot is rebuilt (kxwwsusr) 164a99f0 · 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.