Changes touching this path

• the forge has backups: deployed, and the drill run whole against a real artifact (#813) `npm run setup:forge` has run. /root/.postgres-credentials has a second copy for the first time in its life, and the first journal export took 12 records off the live forge -- 8 burns and 4 revocations that a restore would have put straight back. This was never hypothetical. ADR 0046 section 8, all five steps, against an artifact pulled off R2: The artifact decrypts with the offline key and nothing else. That also settles the interop question I had left open: the VPS encrypts with Ubuntu's Go age 1.1.1 and the key was minted by rage, so one spec and two implementations, proved rather than assumed. The negative is the half that matters and it fires -- restored without the replay, all four capabilities came back; with it, none did. And the recovered 48-character superuser password matches pg_authid's SCRAM verifier, while a wrong one does not. Section 5's real claim is exercised too: the forge's own R2 credential is REFUSED on the backup bucket. An account-wide token would have satisfied every other check in the deploy and silently meant a compromised forge reads seven days of history. The open question in the consequence list is answered. R2 has no versioning endpoint, confirmed against the live API, and the deploy re-asks every run rather than trusting a sentence in a document. Three amendments, each because deploying it falsified something. The artifact now carries pg_dumpall --globals-only. pg_dump -d forge dumps one DATABASE and roles are cluster-level, so a restore had no forge, forge_read or forge_identity -- every GRANT in the archive an error -- and no pg_authid, which is the only thing section 8.5 can check a password against. That step was uncheckable until this landed. Section 8.3 and 8.4 used real rows for the burn and the revocation and fixtures for the publication, and had to: the row-count manifest in that very artifact records publication 0 and published_key 0. The live forge has published nothing yet. That is the same fact that leaves section 7's named trigger unfired. Two of section 2's replay steps still have nothing to mirror, unchanged from the build: the blob delete belongs to a durable job purge.rs says does not exist. What is not proved is said plainly. The timer has never fired on its own schedule -- every run so far was systemctl start from the deploy -- and the age private key has no second copy, which the ADR's own consequence list warns makes every backup landfill. That is now literally true rather than prospective. a2d9f41b · 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.