Changes touching this path

• private api answers carry a Server-Timing header from withPrivateSession, recorded by the new site/src/server/timing.ts: each timed step names itself where it is written, the session verify as verify.pem or verify.jwks and each pool wait and statement as identity, owner, member or membership .wait and .query, each name with its summed duration and run count, then total. a private request looks its account up once through the new sessionAccount, where /repo had looked it up 2 or 3 times and /repos once plus once per key. clerk.ts verifies over CLERK_JWT_KEY, the instance public key, when it is set: without it @clerk/backend refetches the JWKS whenever its copy is 5 minutes old, 12 fetches over a simulated hour at one request every 30 s against at most one per key id with the key, so the clerk.ts header claim of a networkless verify was false and is corrected, as is docs/specs/loot-forge.md. a key id goes to the static key only after a token under it verified over the JWKS, since Clerk files the static key under any key id a token names, in an unbounded cache, before the signature check; a signature the static key refuses goes to the JWKS, refetched at most once a minute, and a key id the JWKS then verifies stays with the JWKS and warns once, so a changed instance key keeps verifying under a new or the same key id, and a refusal on a claim never falls back. measured on a local Postgres through the live suites, the database side of an owned or a member repo read took 1.7 ms with one identity query, and the verify costs about 150 us in process over either key. pinned in private-timing (9 tests), clerk-verify (8) and one test each in owner.pg and member.pg. red under named mutations, each restored: the account looked up per ask (5 failed and 4 passed of 9, and 1 failed and 89 passed over the live suites), the header dropped (3 and 6), the static key for an unlearned key id (5 and 3 of 8), fallback on any refusal (1 and 7), no fallback (5 and 3), no demotion to the JWKS (2 and 6), no forced refetch (2 and 6), refetch unbounded (1 and 7), CLERK_JWT_KEY ignored (6 and 2), escaped line breaks kept (4 and 4). cargo test green, 4831 passed over 144 test result lines with 15 ignored, the site gate green at 909 passed, and the site live suites 90 passed through ci/local.sh. CONTEXT.md gains Private request timing. owes a site deploy, which should set CLERK_JWT_KEY in the site env half (uyzzknlm) 3cfbe0dd · dbf3dbe6…
• the static Clerk key verifies outside the key cache the JWKS copy lives in: clerk.ts byStaticKey makes the category check verifyToken makes and hands a JWK built from CLERK_JWT_KEY to the same verifyJwt with the same options, where verifyToken given the key filed it through loadClerkJwkFromPem marked never to expire, which stopped the JWKS copy expiring, so a key the instance dropped kept verifying over the JWKS until a restart. a refusal Clerk reports as a failed verification goes to the JWKS only when the static key does not verify the signature, so a missing sub or a non-numeric exp, nbf or iat is answered by the static key alone, as the verify doc said and the code did not; the loot-wasm open_sealed_grant, grants.ts keyFor and CONTEXT.md cost claims now add a verify per authored change a grant body carries; the fetch an unknown key id costs is documented; site/test/plan.ts withChangesAtScale inserts inside its try and analyzes again after its deletes; Seam::Gate moved and Converged.moved say what they mean beside the anchor. pinned in 4 new clerk-verify tests: a dropped key stops verifying five minutes after the fetch though the static key verified after it, claim failures answered without the JWKS, HS256 keyed by the public key, the machine category and RS384 refused over both keys, and a key with its line breaks removed read. red under named mutations, each restored, over the 12 clerk-verify tests: the static path back on verifyToken (2 failed and 10 passed), no signature re-check (1 and 11), no category check (1 and 11), the JWK without alg (1 and 11), the PEM read with its armour lines kept (8 and 4); before the fix the new tests went 2 failed and 9 passed of 11. not taken: the span wrapping shared across the pool db.ts files, and running the pg files serially. cargo test green, 4832 passed over 144 test result lines with 15 ignored, the site gate green at 913 passed, and the site live suites 90 passed. owes a site deploy, after which CLERK_JWT_KEY can be set; it also files qpsuxosk, ylrvoopz, the Tickets route server time, and zlulwtlw, the History route live query time, carries a comment on uyzzknlm and resolves zxkpzxvz (qpsuxosk) 96800555 · dbf3dbe6…diff
• review sweep 7 fix-ups of the 2026-09-28 perf afk-loop: the CONTEXT.md Private request timing entry states its rule where it named three timed steps and missed tickets.first, a step times itself by running inside span or spanSync, so the timed steps are the call sites of those wrappers and nothing lists them. byStaticKey is held against Clerk: the new clerk-static-key test hands each token the static key answers, the refusals clerk-verify runs, now one table in test/clerk-tokens.ts, and a token both accept, to verifyToken given the same key, and fails where the verdicts differ. a CLERK_JWT_KEY that is not an RSA public key now warns that it could not be read, where it said the instance signing key had changed. the ledger walk comment records what its seen array costs, measured on a throwaway Postgres 18 over lanes of 2,100 changes walked to the depth cap, a first page in medians of 3: 2 lanes 384 ms against 92 ms for the walk it replaced, with 138 MB of seen spilled to disk, 4 lanes 1,114 against 181, 8 lanes 3,665 against 362, 16 lanes 9,870 against 739 with 1,100 MB; not bounded. the Tickets files comment words its collation as what setup-forge provisions, postgres:18 under the image LANG en_US.utf8 with no locale set, the live database not read. red under named mutations, each restored, over the 13 tests of the two Clerk files: no category check (2 failed and 11 passed), verifyJwt without the authorized parties (2 and 11), the old warning (1 and 12), and verifyToken given a key refusing a token with no sid, a check Clerk could add (1 and 12, clerk-verify green). not taken: a type or lint holding span names to code, since pool callers pass their row type to query explicitly and a literal-only name parameter would change every one of them. cargo test green, 4842 passed over 144 test result lines with 15 ignored, and the site gate green at 915 passed. owes a site deploy; it also files rmwmkyvu, the zlulwtlw walk regression on lane-heavy graphs (uxtrrpuw) e7ccdf4e · 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.