Changes touching this path

• a forge push puts the objects it carries side by side and writes their rows in one call: prepare read the burn state of each object, put it to the blob tier and wrote its row in a transaction of its own, one object at a time, 250-320 ms an object live (6,048 ms for 20); it now reads the burn state of the bundle once, puts the objects through put_blobs, up to MAX_CONCURRENT_PUTS (64) at a time on scoped threads as serve fetch_bytes runs its gets, and writes the rows through the new MetadataStore put_objects once every put has finished, on Postgres one transaction of one burn check and one UNNEST insert, so a refused put leaves no row and a bundle carrying a burned address puts no byte, where one at a time the rows and bytes ahead of either were written. the objects step reports put_ms and put_width beside bundle_objects. the cache put was read for concurrent use: its temp names are unique in the process and its rename and index change under its lock, as the concurrent gets already use it. measured in a test with a tier sleeping 20 ms a put, 136 objects took 2.77 s at 1 in flight before and 62.6 ms at 64 after. pinned in ingest put_cost (3 tests: the width the tier saw with one put_objects call and no put_object, no row after a refused put, no put before a burn refusal), the new conformance cases put_objects_writes_a_whole_list_and_the_first_write_wins and a_list_holding_a_burned_address_writes_none_of_its_rows over the memory store and Postgres 18, and puts_side_by_side_each_land_whole over the memory tier and the cache. before the fix put_cost went 0 passed and 3 failed; red under named mutations, each restored: one put at a time (1 failed and 2 passed), a row write per object (1 and 2), rows before puts (1 and 2), no burn read before the puts (1 and 2), the memory batch writing rows ahead of a burned one (1 and 6), the last row winning in memory (2 and 2), the Postgres batch without its burn check (2 and 1). cargo test green, 4842 passed over 144 test result lines with 15 ignored, and the loot-forge suite green against a throwaway Postgres 18. CONTEXT.md says so. owes a forge deploy and no migration; it also files yznpntky and uxtrrpuw, resolves ppwukxrx and carries a comment on zlulwtlw (wwmonzor) 005fc7fa · 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.