Changes touching this path

• the Tickets list read opens its keys in batches while the object cache is read, in slices that yield to the page, and its cache read no longer waits for the unlock or for a write: loot_codec::envelope::unwrap_envelopes checks many signatures in one batch verification and verifies each alone when the batch does not hold, loot-wasm openSealedGrants passes each grant the gates of openSealedGrant over it, and Keyring.keysFor opens the keys of the list through it 32 at a time and asks keyForSettled for the rest; the object cache read is read-only and the write after it marks what was used, the entries of the list are read as soon as the route answers, under the identity the vault record names, and the read yields every 8 ms (pace.ts). measured in headless chrome over the 2,161 list objects of this repo: key opening 283 to 295 ms before and 205 to 208 after, the longest task 362 to 379 ms before and 80 to 81 after, which is the fold call and stays one task, and the cache read 138 to 177 ms before and 38 to 48 after. the read leaves the measures tickets.unlock, tickets.engine, tickets.cache-read, tickets.keys and tickets.fold. refusal.tsx now states that loot-wasm exports no encrypt, held by a test to the generated surface, where it listed the exports. red under named mutations, each restored: keysFor without the batch (1 failed and 22 passed), without the lone asks after it (1 and 22), a pacer that never yields (1 and 1), a yield to the microtask queue (1 and 1), a cache read that marks uses (1 and 2), a mark for an entry gone (1 and 2), eviction before the marks (1 and 2), the read ahead ignored (1 and 15), read ahead under any identity (1 and 15), keys opened after the objects (1 and 15), no fold measure (1 and 15), an encrypt export (1 failed of 1), a batch that passes unchecked (0 passed and 1 failed in cargo), and openSealedGrants over unverified envelopes (0 and 1 in cargo, 1 and 22 in vitest over the rebuilt wasm). cargo test green, 4888 passed over 144 test result lines with 15 ignored, the site gate green at 958 passed, and the SDK suite 176 passed. CONTEXT.md says so. the wasm gains merlin for the batch, 16.6 KB gzip. owes a site deploy (nqrklwsv) 2bc00291 · dbf3dbe6…
• the Tickets list cache read starts when the route answers, not after the keys: the vault was asked for the reading identity only once the route answered, and its IndexedDB answer then waited behind the key opening, which yielded with scheduler.yield and so resumed ahead of queued tasks. the vault is now asked with the route, and the pacer yields with a message behind the tasks queued: in headless chrome a 2,161 entry read under a 300 ms paced run finished at 334 to 336 ms before and 71 to 74 after, costing the run 23 to 27 ms. each cache read leaves its own measure, tickets.cache-read, tickets.cache-read.whole and tickets.cache-read.answers, tickets.unlock.recall measures the vault read of the unlock over a new unlockRecalled mark, the list read does not read again what the early read covered, the early read is skipped when a held manifest read the list first, and a ticket read whole asks for its keys while its objects are read. the unlock grant premise was measured and the store it proposed was not built: over 8,336 cached grants the grant read and filing cost about 90 ms of a 88 to 137 ms silent unlock, and a store by object took the unlock to 16 to 77 ms but the keys of the 2,161 list objects from 197 to 220 ms to 270 to 299, so the device database stays at version 3. red under named mutations, each restored: the pacer on scheduler.yield (1 failed and 2 passed), the vault asked again once the route answered (1 and 19) or only then (1 and 19), a whole read measured as the list (1 and 19), the early read ignoring a list read from a manifest (1 and 19), a whole read asking for keys after its objects (1 and 19), the list read reading the cache past the early read (1 and 19), and no recall measure (1 and 19). cargo test green, 4888 passed over 144 test result lines with 15 ignored, and the site gate green at 963 passed. CONTEXT.md and ADR 0096 say so. owes a site deploy (qmlkwlkn) 55f8ca4c · dbf3dbe6…diff

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.