Changes touching this path

• a Lock or sign-out in a tab loaded before a deploy that raised the device database version now wipes the vault: wipeVault asked for its own version, which a browser refuses with VersionError once a newer tab has upgraded the database, and lock() stopped before its broadcast, so the seed, the grant cache and the object cache stayed on disk for the next load to unwrap. the wipe now opens the database at whatever version it is, which asks for no version change, the thing an open connection in another tab blocks, rather than deleting it, which such a connection blocks; a lock whose wipe fails still drops the identity, tells the other tabs and publishes the lock carrying the failure, which the gate shows, then throws; each connection vault.ts opens closes on versionchange, and a tab that learns its build is older than the database, by a versionchange past its version or a VersionError, drops the identity and reloads, once for each database version its build knows, so a rolled-back deploy does not reload it forever. pinned in vitest over the in-memory IndexedDB, which now models versions, versionchange and blocked: a wipe of a database a version above the build clears the seed, the grants, the objects and a store the build never named; a lock whose wipe fails drops the identity, broadcasts, publishes the failure and throws; a newer upgrade closes a held connection without being blocked; a stale tab drops its identity and reloads, and a reload that brought back a build of the same version does not reload again. red under named mutations, each restored: the wipe at the build version (1 failed and 4 passed), lock stopping at the failed wipe (1 and 4), the broadcast only on a clean wipe (1 and 4), versionchange leaving the connection open (2 and 3), versionchange not marking the build stale (1 and 4), a VersionError not marking it (1 and 4), the reload without its once guard (1 and 4), and a stale tab keeping its identity (2 and 3). cargo test green, 4886 passed over 144 test result lines with 15 ignored, and the site gate green at 939 passed. CONTEXT.md and ADR 0096 say so. a tab already running a build from before this still runs the old wipe. owes a site deploy (qnkolyzz) 087f3d77 · dbf3dbe6…
• 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…diff
• 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
• the silent unlock reads and files no standing self-grant: the device grant cache keeps each under the object it claims to open, in a store the vault database adds at version 4, and Keyring.keyFor and keysFor read and file the ones for the objects they are asked about, through the same sort and gates, keysFor in one read; the unlock files what is kept under no object, and moves each self-grant kept before under its object in writes of about 2 MiB, since one write of 60 MB held the store for 3.7 to 25 s in headless chrome. the live cache held 10,353 grants and 60,930,133 bytes, each self-grant carrying its object ciphertext, which reversed the verdict of qmlkwlkn, measured over small synthetic grants. over a fixture of that size and spread, up to 298,292 bytes, in headless chrome: the silent unlock 425 to 509 ms before and 68 to 74 after, and 1,224 to 1,303 and 80 to 84 at four times CPU throttling, while the keys of the 2,161 smallest grants went from 220 to 224 ms to 268 to 304, and from 931 to 993 to 1,182 to 1,387 throttled; the first unlock after the change files the old cache once, 440 to 515 ms, and its keys took 340 to 342 ms while the move ran. red under named mutations, each restored: the unlock filing every grant kept by object (5 failed and 13 passed), keyFor not reading them (5 and 13), keysFor not reading them (1 and 17), a grant read by object filed as verified (2 and 16), a read that lands after a lock filing (1 and 17), no move of grants kept before (2 and 16), a cache write without the vault check (1 and 17), the wipe leaving the new store (2 and 21), the count taken only from what is filed (6 and 12), a failed read not asked again (1 and 17), the move in one write (1 and 17), and the move going on past a write that did not land (1 and 17). cargo test green, 4888 passed over 144 test result lines with 15 ignored, and the site gate green at 970 passed. CONTEXT.md and ADR 0096 say so, and correct the qmlkwlkn verdict. a tab on an older build reloads once. owes a site deploy (vuvqoqyz) c89890f7 · dbf3dbe6…diff
• a Lock drops the identity, publishes the lock and tells the other tabs before it awaits the wipe, and tells them again once the wipe settles, where it told them only after the wipe, so a wipe waiting behind another tab upgrade left them unlocked for as long; a tab older than the device database has its open refused with StaleBuild, whose sentence the unlock card shows before and on an unlock: the page must be reloaded from a current build, where a stale tab after a rolled-back deploy read the account tier as unreachable. the Tickets measures take a MEASURE const, the span from the keys to the index is named tickets.keys-to-index for what it spans where it was tickets.fold, and the address width is named once as ADDRESS_BYTES. the ClerkProvider census reads aliased and namespace imports and refuses a use that is not a tag, the workbench frame says Unlocking again once the header is in, refusal.tsx names what defines the set of sealing calls rather than two of them, CONTEXT.md no longer calls every private surface client-rendered, and loot-codec and CONTEXT.md say its batch feature compiles merlin into every build of it. red under named mutations, each restored: the broadcast only once the wipe settles (3 failed and 6 passed), the lock published only once it settles (1 and 8), no broadcast once it settles (2 and 7), the VersionError passed through (4 and 5), the span measured from the fold (1 and 20), the engine measure not left (1 and 20), the frame ignoring unlocking (1 and 9), an aliased provider without the prop (1 and 9), and the census without aliases (2 and 8). cargo test green, 4897 passed over 144 test result lines with 15 ignored, and the site gate green at 981 passed. ADR 0096 says so. owes a site deploy (qrsypwtv) 8caf1999 · dbf3dbe6…diff
• a Lock now closes the workbench cache, where the Tickets view kept the flat runs of content keys it handed the core, with the folds they opened, after the keyring had zeroed its own: forgetInMemory, the path every end of an unlock takes, empties and closes each held SessionCache, a write to one after that keeps nothing so a read in flight puts nothing back, WorkbenchContext.cache is typed as one so a plain Map is not assignable to it, and the workbench takes a new one for the next unlock. a read of the Tickets list again after a write reuses keys only when the keyring that opened the list shown is the one of this session, and otherwise reads from nothing. each lock telling carries the time the lock began, and a tab whose reader unlocked by passphrase or words after it keeps that unlock, where the telling sent once the wipe settles relocked it; an unlock recalled from the vault is relocked by any telling, and every unlock by a bare lock message from an older build. the broadcast doc no longer says a told tab re-reads the vault, and a silent unlock that throws, as on an IndexedDB error, says why on the unlock card. pinned: no fixture key reachable from the cache once the unlock ends, a read in flight putting nothing back, a read again under another identity asking its own keyring for every key, and the lock rules. red under named mutations, each restored: forget not closing caches (2 failed and 1 passed), a closed cache still keeping writes (1 and 2), reuse under any keyring (1 and 2), a lock telling ignoring the unlock time (2 and 3), a silent unlock counted as asked (1 and 4), a message without a time read as time zero (1 and 4), a released cache still held (1 and 4), and the card reason left bare (1 and 4). cargo test green, 4919 passed over 144 test result lines with 15 ignored, and the site gate green at 1006 passed. CONTEXT.md and ADR 0096 say so. owes a site deploy (kqpqnmqx) 80ed4a15 · dbf3dbe6…diff
• a failure inside an unlock now ends it through forgetInMemory, which publishes locked, so the unlock card is usable where it sat disabled on unlocking, and a silent unlock throws the failure for the card to say, as for an engine that does not load, with the vault record kept; a vault holding a key the account holds retired asks for a key as one it does not hold does, where it unlocked as that key, and forgetInMemory forgets the keyring an unlock built before publishing it. also fixes yvonuouo: a lock telling carries an id, weighed at the time the tab first heard it by performance.now, where a time from Date.now could step backward and leave an unlock standing; an unlock takes its generation when asked for and stops at its next step once an end moves it, removing a seed it stored meanwhile, and a relocked unlock removes the seed it stored when still the one stored; forgetInMemory closes every workbench cache made since the last end, one no workbench shows included, so such a cache stays in memory until the unlock ends. red under named mutations, each restored, failed and passed of 24: no end on a failure (5 and 19), the silent catch swallowing every failure (2 and 22), a retired key not filtered (1 and 23), a wrong identity thrown (2 and 22), the built keyring not forgotten (2 and 22), a cache not kept from construction (2 and 22), the wall clock (2 and 22), no check once the engine loads (2 and 22), a seed stored as the lock was heard kept (1 and 23), a relock keeping its seed (1 and 23), and no check once the keyring is restored (1 and 23). cargo test green, 4919 passed over 144 test result lines with 15 ignored, and the site gate green at 1016 passed. CONTEXT.md and ADR 0096 say so. owes a site deploy (knqurkks) 8e9e4b6f · 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.