Changes touching this path

• the private workbench asks for the head manifest beside the repo header from the moment Clerk has a token, instead of after /me, the unlock and /api/private/repo in series: PrivateGate takes an ahead render prop, handed null while the account is read and the silent unlock runs and the session once unlocked, at the same place in the tree, and the workbench renders its header read through it; the new components/workbench/manifest.ts, where the manifest slot moved from the Files view data module, has readRepo issue the tip manifest and /api/private/repo together into the workbench cache, and the shell, where files and tickets open, still mounts only once the header and the unlock are both in. the gate starts the engine download and compile when it mounts, while Clerk loads, rather than after /me answers. the Tickets list /fetch starts from the tickets/ entries of the tip manifest beside /api/private/tickets rather than after it, and its answer is folded only when the route answers the same heads and files, else the list is fetched again over the route answer; a reread after a write leaves it off. the CSP is unchanged. pinned in the new site/test/workbench-first-reads.test.ts and 2 new tests in workbench-tickets-read.test.ts. red under named mutations, each restored, over the 5 tests of those two files: the header awaited before the manifest (4 passed and 1 failed), the list fetch waiting for the route (3 and 2), the manifest answer folded whatever heads the route answers (4 and 1), the manifest answer never folded (2 and 3). the site gate green at 886 passed; site only, no Rust touched and no cargo test run. owes a site deploy (kwlxstko) 89c6e267 · dbf3dbe6…
• the Tickets view keeps the forge objects it reads in a browser cache and reads no code manifest: the list, a ticket read whole and the answers now take each object an IndexedDB cache in the vault database holds by content address, once the core has decoded the entry as the object at that address, and ask the forge /fetch only for the rest, so a repeat visit moves only new objects. an entry is a sync frame holding one object, ciphertext only, and an object whose key rode in the forge answer is not kept; the cache is bounded at 32 MiB, evicts the least recently used, is wiped with the vault, and reads as empty where storage is missing. the workbench asked for the whole head manifest on every entry and opened the explorer first, so a Tickets visit moved the whole tree, about 376 KB gzip as the ticket measured it: a view now has an ahead hook the shell runs beside the repo header, Files asks for the manifest there and Tickets for its route, and the shell opens the side panel of the view it was entered at, so a History link now opens the History panel; the list fetch starts from a manifest only when one is already held. pinned in vitest: a repeat visit asks the forge for nothing, a partial hit asks only for the misses, a damaged entry and an entry of another object are refused and asked for again, no keyed object is kept, a write lands only while the vault holds the identity, no storage asks every time, and a Tickets entry reads the route asked ahead and no manifest; and in loot-wasm, what an entry is and what it refuses. red under named mutations, each restored: the cache read skipped (3 failed and 11 passed), every want fetched on a miss (2 and 12), entries held unchecked (1 and 13), the list fetch loading the manifest (2 and 12), the entry view ignoring the document (1 and 13), the vault check dropped (1 and 11), an entry held under any address (1 failed and 3 passed in cargo, 1 and 10 in vitest), and keyed objects kept (1 and 3 in cargo, 1 and 10 in vitest). cargo test green, 4886 passed over 144 test result lines with 15 ignored, and the site gate green at 925 passed. owes a site deploy (qqypkwst) b7bcb3b5 · 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.