Changes touching this path

• a burn and a push at the forge no longer leave a key or bytes behind each other: the ingest transaction files no published_key row for a burned address, reading the tombstones after taking a shared advisory lock per key address, which record_burn now takes exclusively before its tombstone and key delete, so a key presented after a burn is dropped and one a racing ingest wrote but had not committed is waited for and deleted, where at READ COMMITTED the burn could not see it and the ingest read burn state only for the objects a bundle carries; the memory store drops a burned key under the lock record_burn takes; and prepare reads the burn state again after its puts and deletes the bytes of any burned address it put before refusing the push, so a burn landing between the burn read and a put cannot have its bytes put back behind the delete of the durable job, which #482 section 5 orders after the tombstone and which is not built yet. on Postgres the key reads found serving a key, live_published_key and the forge_read_published_key view, exclude tombstoned addresses, so the surviving row was key material at rest in the live database and its dumps rather than a served key; the memory store served it. pinned in the conformance case an_ingest_after_a_burn_files_no_key_for_the_burned_address over memory and Postgres 18, the pg race test a_burn_racing_an_ingest_leaves_no_published_key, which pauses the ingest after its key rows and starts the burn there, ending the pause when the burn finishes or waits in pg_locks, and a_burn_during_the_puts_leaves_no_bytes over memory and Postgres, whose blob tier records the burn and deletes the bytes inside the put of the victim. before the fix the five went 0 passed and 5 failed; red under named mutations, each restored, over the 8 selected tests: no burn lock (1 failed and 7 passed), no ingest lock (1 and 7), the Postgres ingest keeping burned keys (1 and 7), the memory ingest keeping them (1 and 7), no re-read after the puts (3 and 5), the re-read without its delete (2 and 6). cargo test green, 4851 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 wosupkwz, the burn delete job that was never built (uzkouqqx) 789387b0 · 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.