Signed-in navigation no longer waits on the session read

Three changes from issue #189. They were measured on the built Worker in local workerd with a production-like latency profile: the browser 120 ms from the Worker, the database 20 ms away. A second profile put the database 110 ms away. Medians of 3 rounds.

• The /_auth guard is stale-while-revalidate. Once the cached session was older than 15 s, every signed-in navigation waited for GET /api/auth/get-session before the page's own loaders started. The guard now lets the navigation start on a cached signed-in session and re-reads it in the background; a signed-out answer sends the layout to /login. A navigation after 20 s idle went from about 220 ms to about 45 ms, and from about 820 ms to about 45 ms with the distant database. (c38e801)

• GET /get-session runs outside the request transaction. Every auth request ran in db.transaction, so a session read cost BEGIN, the read and COMMIT. It is now one statement; every other auth request keeps its transaction. (f987550)

• The browser's session read comes from Better Auth's cookie snapshot. session.cookieCache is on (compact, 60 s). The browser's presentation read no longer sends disableCookieCache, so a tab focus or a background revalidation costs no database statement. With the distant database, get-session dropped from about 290 ms to 8 ms. Authorization never uses the snapshot:

  • SSR, the oRPC context, the files gateway and admin still read the database;
  • the auth handler strips the snapshot from every other /api/auth/* request;
  • the web app re-reads from the database after its own session changes.

  Creating an Organization on the web now switches to it, as Better Auth and the native app already did. A session revoked on another device can keep the UI shell for up to 60 s, and its first data request is refused with 401. See Session reads.