Changes touching this path

• an unlock files its cached self-grants without verifying their signatures: Keyring.file reads each blob through the new wasm peekSealedGrant (the claimed grantor and header, over the new loot_codec::envelope::split_unverified, the split unwrap_envelope now reads through too) and indexes a blob claiming this identity unchecked, while a foreign offer is still verified on arrival since the pending list shows it before any apply. keyFor answers nothing from an unchecked entry until its signature holds: an entry key comes out only through applySealedGrant, whose gate 0 verifies the same bytes, a header lock (expired, not yet revealed) is answered only after an unwrapEnvelope verify, and an entry whose signature fails is dropped as if never filed; addressCount counts an unchecked entry until a lookup drops it. measured over the real restoreMailbox in node with 7,824 cached self-grants: 664-755 ms before and 46-69 ms after, with 7,824 signature verifies before and 0 after, and 130-176 ms after over 20,000; opening a self-grant pays one verify, inside the apply, where it paid two. pinned in 3 new private-grants tests (the verify counts, a stranger grant relabelled as a self-grant refused at open and dropped, no lock from a forged header) and a loot-wasm and a loot-codec test. red under named mutations, each restored: filing verifies each self-grant (18 passed and 2 failed), a header lock answered unchecked (19 and 1), checked trusting an unverified entry (18 and 2), applySealedGrant reading the envelope unverified (19 and 1 over the site file, where the relabelled grant opened, and 17 and 2 over the loot-wasm grant_tests). cargo test green, 4829 passed over 144 test result lines with 14 ignored, and the site gate green at 892 passed. CONTEXT.md says so. owes a site deploy (pnwlklpl) 29207fed · 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.