Changes touching this path

• the Tickets view opens a self-grant key with one signature verify and one unseal: the core gains open_sealed_grant, wasm openSealedGrant, which passes the gates of apply_sealed_grant through the new shared gated and hands the content key back unwrapped, and none for a grant not yet due, and Keyring.keyFor opens through it where it applied the grant, re-wrapping the key to this identity, and then unsealed that wrap again; accept keeps applySealedGrant for a foreign grant. measured in node over the perf hunt dump with a nodejs build from this tree, three runs: the 2,161 keys the list read opens took 701-705 ms before and 314-319 ms after, 324-326 us an object before and 145-148 us after, against 72-74 us for the verify alone, and all 5,484 took 1,778-1,812 ms before and 793-798 ms after; readTicketList over the list took 96-152 ms. pinned in private-grants, where a key open is 1 openSealedGrant and 0 applySealedGrant, unsealKey and further unwrapEnvelope calls, and a second ask opens nothing, and in the new loot-wasm test the_open_passes_the_apply_gates_and_hands_back_the_key_only_when_due. red under named mutations, each restored: keyFor back on apply then unsealKey (1 failed and 19 passed of 20), the open handing a key while escrowed (1 failed and 19 passed over the 20 grant_tests), gate 0 read through split_unverified (3 failed and 17 passed). not built: moving key opening and readTicketList into a Web Worker, which needs the identity seed or the keyring in a second realm, a decision left open in the ticket. cargo test green, 4832 passed over 145 test result lines with 15 ignored, the site gate green at 909 passed, and the SDK suite 176 passed. CONTEXT.md says so. owes a site deploy, which carries the rebuilt wasm; it also files nqrklwsv, the yield that moves no key material (oytwyrxw) 80e3e420 · 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.