Changes touching this path

• the forge stops saying it does not know its own window: ADR 0046 section 9 last step, taken (#813) The media existed and the bucket enforced the window, while /info still answered backup_retention_days null -- so `loot burn` went on printing an unknown-retention line against a forge that does in fact keep a copy for seven days. Section 9 assigns that key to this ticket in as many words, and it was the one step nobody had taken. https://forge.millerbyte.com/info now answers 7. Written only when the backup half is on, because section 9 rule cuts both ways and a window nobody keeps is the worse lie. In the env half rather than the mounted credentials file: it is not a secret, and the drift check greps it out of docker inspect, so moving it would blind that check while everything kept appearing to work. And the part that makes it a fact rather than a claim. A container reads its environment at CREATE, so one older than the backup half advertises null however often the script rewrites .env.forge. That is drift now, and it fired on the real deploy before recreating; probeForge then asserts /info returns the number, which is the only place the answer belongs to the running process rather than to a file this script wrote. Section 9 says the advertised number and the rule enforcing it are tied by one key name written once at deploy. They are tied a little better now -- one RETENTION_DAYS constant feeds both -- and the bucket is still the enforcer. 630c9069 · 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.